Master the core knowledge points of JVM garbage collection in ten minutes

garbage collection

As the program runs, more and more memory is occupied by instance objects, variables, etc. in the memory. If it is not recycled in time, it will reduce the efficiency of the program and even cause system exceptions. The JVM will automatically complete the garbage collection, mainly including:

  • Minor GC/Young GC:  Garbage collection for the young generation.
  • Major GC/Old GC:  Garbage collection for the old generation.
  • Full GC:  Garbage collection for the entire Java heap and method area.

The Java heap area can be divided into the new generation and the old generation, and the new generation can be further divided into the Eden area, the Survivor 1 area, and the Survivor 2 area. For specific scale parameters, you can look at this picture.

Garbage Collection Principles

Under normal circumstances, newly created objects will be allocated to the Eden area (some large objects are specially treated). After the first Minor GC, if these objects are still alive, they will be moved to the Survivor area. Every time the object survives Minor GC in the Survivor area, the age will increase by 1 year, and when its age increases to a certain extent, it will be moved to the old generation. Because the objects in the young generation are basically dead (more than 80%), the garbage collection algorithm in the young generation uses the copy algorithm. The basic idea of ​​the copy algorithm is to divide the memory into two blocks, each time only use One of the blocks, when this block of memory is used up, copies the objects that are still alive to the other block. The copy algorithm does not generate memory fragmentation. At the beginning of the GC, the object will only exist in the Eden area and the Survivor area named "From", and the Survivor area "To" is empty. Immediately after the GC, all surviving objects in the Eden area will be copied to "To", while in the "From" area, surviving objects will decide where to go according to their age values. Objects whose age reaches a certain value (age threshold, which can be set by -XX:MaxTenuringThreshold) will be moved to the old generation, and objects that do not reach the threshold will be copied to the "To" area. After this GC, the Eden area and From area have been emptied. At this time, "From" and "To" will exchange their roles, that is, the new "To" is the "From" before the last GC, and the new "From" is the "To" before the last GC. Either way, the Survivor area named To is guaranteed to be empty. Minor GC will repeat this process until the "To" area is filled, and after the "To" area is filled, all objects will be moved to the old generation.

Garbage Collection Algorithm

The mark-to-clean algorithm is to mark invalid objects and then clear them.

The mark-copy algorithm is to divide the Java heap into two parts, use only one of them for each garbage collection, and then move all surviving objects to another area.

The mark-to-clean algorithm is a compromised garbage collection algorithm. In the process of object marking, the same steps are performed as the previous two. However, after marking, the surviving objects are moved to one end of the heap, and the area outside the surviving objects can be cleaned up directly. In this way, memory fragmentation is avoided, and there is no such thing as a waste of heap space. However, every time garbage collection is performed, all user threads must be suspended, especially for objects in the old age, which requires a longer collection time, which is very bad for the user experience.

garbage collector

In the JVM, GC is performed by the garbage collector. Therefore, in practical application scenarios, we need to choose a suitable garbage collector. Let's introduce the garbage collector.

Serial collector

The Serial collector is the most basic and oldest collector. It is a single-threaded collector. Using the Serial collector, whether it is Minor GC or Full GC, all application threads will be suspended when the heap space is cleaned up.

ParNew collector

The ParNew collector is essentially a multi-threaded parallel version of the Serial collector. In addition to using multiple threads for garbage collection at the same time, the rest of the behavior includes all the control parameters available to the Serial collector, collection algorithms, Stop The World, and object allocation rules. , the recycling strategy, etc. are exactly the same as the Serial collector.

Parallel Scavenge Collector

The Parallel Scavenge collector is also a new generation collector based on the mark-copy algorithm. The multi-threaded collector that can collect in parallel is very similar to ParNew. The goal of the Parallel Scavenge collector is to achieve a manageable throughput (Throughput). Throughput is the ratio of the time the processor spends running user code to the total processor time. If the virtual machine completes a task, user code plus garbage collection takes a total of 100 minutes, and garbage collection takes 1 minute, then the throughput is 99%.

Serial Old collector

Serial Old is the older version of the Serial collector, which is also a single-threaded collector and uses a mark-and-collate algorithm.

Parallel Old collector

Parallel Old is the old version of the Parallel Scavenge collector, which supports multi-threaded concurrent collection and is implemented based on the mark-collate algorithm.

CMS collector

The CMS collector is designed to eliminate long pauses in the Parallel and Serial collector Full gc cycles. The CMS collector suspends all application threads during Minor gc and performs garbage collection in a multi-threaded manner.

G1 collector

The G1 garbage collector is a new garbage collector introduced after Java7 update 4. G1 is a generational, incremental, parallel and concurrent mark-copy garbage collector. It's designed to accommodate today's ever-expanding memory and ever-increasing processor counts, further reducing pause times while maintaining good throughput.

A graph summarizing the comparison of various GC collectors:

Guess you like

Origin blog.csdn.net/Trouvailless/article/details/124434748