Java garbage collection mechanism

Garbage Collection The GC (garbage Collection) is intended to clear objects that are no longer in use. The GC determines whether to collect the object by determining whether the object is referenced by the active object. The GC first determines whether the object is ready to be collected. Two common methods are reference counts and object reference traversal.

Reference count Collector

The reference count is an early policy in the garbage collector. In this approach, each object (not a reference) in the heap has a reference count. When an object is created, and the object is assigned to a variable, the variable count is set to 1. When any other variable is assigned a reference to this object, the count is added 1 (a = B, then B refers to object +1), but the reference count of the object is reduced by 1 when a reference to an object exceeds the life cycle or is set to a new value. Any object with a reference count of 0 can be garbage collected. When an object is garbage collected, it refers to any object count minus 1.

Advantage: The reference counting collector can be executed very quickly, interwoven in the program running. It is advantageous to the real-time environment that the program is not interrupted for a long time.

Disadvantage: cannot detect a circular reference. If the parent object has a reference to a child object, the child object in turn references the parent object. In this way, their reference count will never be 0.

Trace Collector

Earlier JVMs used reference counting, and most JVMs now traverse with object references. Object reference traversal starts with a set of objects and recursively determines the reachable (reachable) object along each link on the entire object graph. If an object cannot arrive from one (at least one) of these root objects, it is garbage collected. During the object traversal phase, the GC must remember which objects can be reached in order to delete the Unreachable object, which is known as the markup (marking) object.

Next, the GC wants to delete the unreachable object. When deleted, some GC simply scans the stack, removes unmarked unmarked objects, and frees their memory to generate new objects, called Purge (sweeping). The problem with this approach is that memory is broken into small chunks, which are not sufficient for new objects, but are very large in combination. As a result, many GCs can reorganize objects in memory and compress (compact) to make available space.

To do this, the GC needs to stop other active activities. This approach means that all application-related work is stopped and only the GC is running. As a result, many miscellaneous requests are added and subtracted during the response. In addition, more complex GCS are constantly increasing or running concurrently to reduce or eliminate the interruption of the application. Some GC uses a single thread to do the work, while others use multithreading to increase efficiency.

Some common garbage collectors

(1) Mark-Clear collector

The collector first loops through the object graph and marks the reachable objects, then scans the stack for unmarked objects and frees up their memory. This collector typically uses a single thread to work and stops other operations. Also, because it clears only those unmarked objects and does not compress the tagged objects, it can result in a lot of memory fragmentation, which wastes memory.

(2) Tag-compression collector

Sometimes also called Mark-purge-compress collector, with the mark-purge collector has the same marking stage. In the second stage, the tag object is copied to the new domain of the stack to compress the stack. This collector also stops other operations.

(3) Copy Collector

This collector divides the stack into two domains, often referred to as half-space. Using only half of the space at a time, the new object generated by the JVM is placed in the other half of the space. When the GC runs, it compresses the stack by copying the reachable object to the other half of the space. This method is suitable for short-lived objects, and continuous replication of long-lived objects results in reduced efficiency. And for a given size heap, it takes twice times the size of memory, because only half of it is used at any time.

(4) Incremental collector

The incremental collector divides the stack into multiple domains, collecting garbage from only one domain at a time, or it can be understood to divide the stack into a small chunk, one at a time, and only one block is garbage collected. This results in a smaller application outage time, which makes the user generally unaware that the garbage collector is working.

(5) Generational collectors

The disadvantage of the copy collector is that all tagged objects are copied each time they are collected, causing objects with long life cycles to be copied back and forth multiple times, consuming a lot of time. The generational collector solves this problem by dividing the stack into two or more domains for storing objects of different lifetimes. A new object generated by the JVM is typically placed in one of the domains. Over time, objects that continue to exist (non-short-lived objects) will receive a lifetime and go into a longer-lived domain. The generational collector uses different algorithms for different domains to optimize performance.

Parallel collector

The parallel collector uses some traditional algorithms and uses multithreading to perform their work in parallel. The use of multithreading on multi-CPU machines can significantly improve the scalability of Java applications.

Finally, a very simple example of a tracking collector is posted so that you can deepen your understanding of the collector:

Trace collector Legend

Where to pay attention to using the garbage collector

Here are some things to note about the garbage collector, the garbage collector has a lot of knowledge, and here are just a few of the necessary knowledge:

(1) Each object can only call the Finalize () method once. If an exception (exception) is generated when the Finalize () method executes, the object can still be collected by the garbage collector.

(2) The garbage collector tracks each object and collects the inaccessible objects (that is, the object is no longer referenced by the program) and reclaims the memory space it occupies. However, when garbage collection is in progress, the garbage collector invokes the Finalize () method of the object, if any. If, in the Finalize () method, the object is referenced by a program (commonly known as resurrection), the object becomes a reachable object and is not garbage collected for the time being. However, because each object can only be called once by the Finalize () method, each object can only be "resurrected" once.

(3) The Java language allows programmers to add a Finalize () method to any method that is called before the garbage collector swaps the objects. However, do not rely too much on this method to recycle and reuse system resources because the execution results after the method invocation are unpredictable.

(4) The garbage collector cannot be enforced, but the programmer can suggest that garbage collection be performed by investigating the System.GC method. Remember, it's just a suggestion. It is generally not recommended to write System.GC, because it will increase the amount of garbage collection.

Java garbage collection mechanism