Detailed explanation of Java garbage collection _java

1. The core idea of garbage collection algorithm
The Java language establishes a garbage collection mechanism for tracking objects that are in use and for discovering and reclaiming objects that are no longer in use (references). This mechanism can effectively guard against the two risks that may occur in dynamic memory allocation: the memory exhaustion caused by excessive memory garbage, and an illegal memory reference caused by improper memory release.

The core idea of the garbage collection algorithm is: the virtual machine available memory space, that is, the object in the heap space to identify, if the object is being referenced, then call it the living object, conversely, if the object is no longer referenced, then the garbage object, you can reclaim its occupied space for redistribution. The selection of garbage collection algorithm and the reasonable adjustment of the parameters of garbage collection system directly affect the performance of the system, so it is necessary for the developers to have a more in-depth understanding.

2. Conditions that trigger the main GC (garbage Collector)
The JVM has a high frequency of GC, but because the GC takes a very short time, it has little impact on the system. What is more noteworthy is the trigger condition of the primary GC, because it has an obvious effect on the system. In general, there are two conditions that trigger the primary GC:

(1) When the application is idle, the GC is invoked when no application thread is running. because the GC is in the lowest-priority thread, the GC thread is not invoked when the application is busy, except for the following conditions.

(2) The GC is invoked when the Java heap is low on memory. when the application thread is running and a new object is created during the run, if there is not enough memory space, the JVM is forced to call the GC thread to reclaim the memory for the new assignment. If the GC is not able to meet the requirements of memory allocation after the first time, the JVM will do two more GC for further attempt, if still unable to meet the requirements, the JVM will report "Out of Memory" error, the Java application will stop.

Because the main GC is determined by the JVM based on the system environment, and the system environment is constantly changing, the main GC runs with uncertainty and cannot predict when it will inevitably occur, but it can be determined that the main GC is repeated for a long-running application.

3. Measures to reduce GC overhead
According to the above GC mechanism, the operation of the program will directly affect the system environment changes, thus affecting the GC trigger. If you do not design and encode the characteristics of GC, there will be a series of negative effects such as memory presence. To avoid these effects, the basic principle is to minimize garbage and reduce the cost of the GC process as much as possible. Specific measures include the following:

(1) Do not explicitly call System.GC ()
This function recommends that the JVM be the primary GC, although it is recommended rather than certain, but in many cases it triggers the primary GC, which increases the frequency of the primary GC, and increases the number of intermittent pauses. It is particularly important to note that the call System.GC () shown in the code does not necessarily make the GC, which we can verify through the Finalize () method, that is, to invoke System.GC () voluntarily, and not necessarily to call the Finalize () method each time. The Finalize () method is characterized by calling the Finalize () method first before the object is reclaimed.

(2) Minimizing the use of temporary objects
The temporary object becomes garbage after the function call is dropped, and the less temporary variable is the equivalent of reducing garbage generation, thus prolonging the occurrence of the second triggering condition mentioned above and reducing the chance of the primary GC.

(3) It is best to explicitly null an object when it is not in use
In general, NULL objects are treated as garbage, so it is more efficient for GC collectors to determine garbage by explicitly setting unused objects to null.

(4) try to use StringBuffer instead of string to accumulate strings (See blog Another article Java string and StringBuffer)
Because string is a fixed-length string object, accumulating a string object is not amplified in a string object, but rather creates a new string object, such as STR5=STR1+STR2+STR3+STR4, that produces multiple garbage objects during execution. Because a new string object must be created for the secondary "+" operation, these transition objects are meaningless to the system and will only add more garbage. To avoid this situation, you can use StringBuffer to accumulate strings, because the StringBuffer is variable length, it expands on the original basis, does not produce intermediate objects.

(5) can use basic type such as Int,long, do not use Integer,long object
The base type variable consumes much less memory resources than the corresponding object, and if it is not necessary, it is best to use the base variable. Under what circumstances do I need to use integer?

(6) Use of static object variables as little as possible
Static variables are global variables and are not reclaimed by GC, and they can occupy memory all the time.

(7) Time to create or delete dispersed objects
Focusing on a large number of new objects in a short time, especially large objects, can result in a sudden need for large amounts of memory, which, in the case of the JVM, can only be primary GC to reclaim memory or consolidate memory fragmentation, thereby increasing the frequency of the primary GC. The same is true for deleting objects centrally. It causes a sudden emergence of a large number of garbage objects, the inevitable reduction of free space, thereby greatly increasing the next time to create a new object to force the main GC opportunity.

4. Garbage collection algorithm
(1) Reference counting collector
Reference counting is an early strategy for garbage collection. In this approach, each object in the heap has a reference count. When an object is created, and a reference to the object is assigned to a variable, the reference count of the object is set to 1. For example, create a new object a a=new a (), and then A is assigned to another variable B, that is, b=a; then the reference count of object A is +1. When any other variable is assigned to a reference to this object, the count is plus 1. When an object's reference exceeds its lifetime or is set to a new value, the object's reference count is reduced by 1, such as B=c, then A's reference count-1. Any object with a reference count of 0 can be garbage collected. When an object is garbage collected, it references any object count minus 1. In this approach, an object that is garbage collected can cause garbage collection actions for subsequent objects. such as a a=new a (); b=a; when b is garbage collected, the reference count of a becomes 0, which causes a to be garbage collected.

the benefit of the method: The reference counting collector can be executed quickly and interleaved in the running of the program. This reminder is good for a real-time environment where programs cannot be interrupted for long periods of time.

Disadvantages of the method: the reference count cannot detect loops (that is, two or more objects are referenced to each other). Example of a loop, where a parent object has a reference to a child object, which in turn refers to the parent object. It is impossible for an object user to count to 0, even if they cannot be touched by the root object of the executing program. Another disadvantage is that each reference count increases or decreases with additional overhead.

(2) Tracking collector
Garbage detection is typically achieved by establishing a collection of root objects and examining the accessibility that begins with these root objects. This object is accessible if the executing program can access the root object and a reference path between the objects. The root object is always accessible to the program. Starting with these root objects, any object that can be touched is an object that is considered "active." Objects that cannot be touched are considered rubbish because they do not affect the future execution of the program.

A trace collector is an object reference graph that tracks the start of a root node. Objects encountered during the tracing process are marked in a hand manner. In general, either set the tag on the object itself or use a separate bitmap to set the tag. When the trace is finished, the unmarked object is unreachable and can be collected.

The basic tracking algorithm is called "Mark and Purge." The name points to two stages of the junk phone. In the markup phase, the garbage collector traverses the reference tree, marking each object encountered. In the purge phase, objects that are not marked are freed, and the memory that is obtained after the object is disposed is returned to the executing program. In the Java Virtual machine, the purge step must include the end of the object.