Easily learn JVM (5) - garbage collector
In the previous article, we introduced common garbage collection algorithms. Different algorithms have their own advantages and disadvantages. In the JVM, we do not simply use a certain algorithm for garbage collection, but wrap different garbage collection algorithms in different garbage collection algorithms. Among the garbage collectors, users can use different garbage collectors according to their own needs in order to maximize the performance of their Java programs.
Before introducing the garbage collector, let's review the structure of the Java heap.
Heap Memory Review
The Java heap memory structure includes: the new generation and the old generation. The new generation consists of an Eden area and two survivor areas. The two survivor areas are of the same size and completely symmetrical without any difference. We call them S0 area and S1 area, also can be called from area and to area.
The garbage collection of the JVM is mainly for the garbage collection of the above heap space. Of course, it will also be garbage collected for the metadata area (permanent area). Here we mainly introduce the garbage collection of the heap space.
Below we introduce several types of garbage collectors:
Serial collector
As the name suggests, the serial collector uses a single thread for garbage collection. The replication algorithm is used for the recycling of the new generation, and the mark compression algorithm is used for the old generation, which is also consistent with the advantages of the algorithm we introduced in the previous article.
The serial collector is the oldest and most stable collector. Although it is a serial collector and has a longer recovery time, its stability is better than other collectors. In general, it is a good choice. To use the serial collector, you can start the configuration with the following parameters:
-XX:+UseSerialGC
The execution flow of the serial collector is as follows:
When garbage collection is performed, the application thread is suspended, the GC thread starts (starts garbage collection), and after the garbage collection is completed, the application thread continues to execute. Note: Use a single thread for serial recycling while the GC thread is running.
Parallel collectors
You may have guessed that the parallel collector is to use multi-threaded parallel collection, but it should be noted here that whether to use parallelism for both the new generation and the old generation, there are different collector options:
1. ParNew collector
This collector only performs concurrent collection for the young generation, and the old generation still uses serial collection. The recycling algorithm is still the same as serial recycling. The new generation uses the replication algorithm, and the old generation uses the mark compression algorithm. Under multi-core conditions, its performance is obviously better than the serial collector. If you want to use this collector, you can configure it in the startup parameters:
-XX:+UseParNewGC
If you want to further specify the number of concurrent threads, you can configure the following parameters:
-XX:ParallelGCThreads
The process of the ParNew collector is shown in the following figure:
The application thread is still suspended during garbage collection, and the GC thread starts to perform garbage collection in parallel. After the garbage collection is completed, the application thread continues to execute.
2. Parallel Recycler
It is still a parallel collector, but this collector has two configurations, one is similar to ParNEW: the new generation uses parallel collection, and the old generation uses serial collection. It differs from ParNew in that it pays more attention to throughput as a design goal, and it can be considered better than ParNew under the same conditions. To use this collector can be configured in the launcher:
-XX:+UseParallelGC
Another configuration of the Parallel collector is different from ParNew. Both the new generation and the old generation are suitable for parallel collection. To use this collector, you can configure it in the startup program:
XX:+UseParallelOldGC
The process of the Parallel collector is the same as that of ParNew:
When the collection is in progress, the application is suspended, the GC uses multi-threaded concurrent collection, and the application thread continues to run after the collection is completed.
CMS Recycler
CMS collector: Concurrent Mark Sweep, concurrent mark sweep. Note two words here: concurrency, mark-sweep.
Concurrency means that it can execute concurrently and alternately with the application; mark-sweep means that this collector does not use a mark-compression algorithm, which is different from the serial collector and concurrent collector described earlier. It should be noted that the CMS collector is a collector for the old generation and does not affect the new generation. The advantage of this type of collector is that it reduces the amount of time the application is stalled, because it does not require the application to complete tentatively waiting for garbage collection, but executes concurrently with garbage collection. To implement this garbage collector can be configured in the startup parameters:
-XX:+UseConcMarkSweepGC
The operation mechanism of the CMS recycling machine is very complicated. We simply divide its operation process into the following steps:
initial mark
Mark objects that are directly reachable from the GC Root;
Concurrency marking (with application threads)
The main marking process, marking all objects;
relabel
Since the user thread is still running during concurrent marking, it is necessary to re-mark and correct it before the official cleanup.
Concurrent cleanup (with user threads)
Based on the marked result, the object is cleaned up directly.
The process is shown in the figure below:
As can be seen from the above figure, the marking process is divided into three steps: initial marking, concurrent marking, and re-marking. Concurrent marking is the most important marking process, and this process is executed concurrently and can be performed simultaneously with application threads. Initial marking and re-marking Although the marking cannot be executed concurrently with the application, these two processes have fast marking speed and short time, so it will not have much impact on the application. The final concurrent clearing process is also carried out at the same time as the application, which avoids application pause.
The advantage of CMS is obvious, that is, it reduces the pause time of the application, so that the recycling thread and the application thread can execute concurrently. But it is not perfect, as can be seen from its operating mechanism, because it does not collect garbage for a period of time like other collectors, and the application is still running when it is collected, so its collection is not complete. This also causes the CMS to recycle more frequently than other collectors, which will affect the throughput of the application.
G1 Recycler
The G1 collector is a collector launched after jdk1.7, trying to replace the CMS collector.
Unlike other collectors, G1 divides the heap space into independent blocks. Each area may belong to both the old generation and the new generation, and the space of each type of area can be discontinuous (the old generation and the new generation of CMS must be continuous). This idea of dividing the old generation into multiple chunks stems from the fact that when concurrent background threads are looking for recyclable objects, some chunks contain much more recyclable objects than others. Although G1 still needs to suspend the application thread when cleaning up these blocks, it can preferentially reclaim the blocks containing the most garbage in relatively less time. This is why G1 is named Garbage First: the blocks with the most garbage are processed first. To use the G1 collector, you need to configure the following parameters at startup:
-XX:+UseG1GC
The advantages of G1 over CMS collectors are:
1. Because many blocks are divided, the generation of memory fragments is reduced during recycling;
2. G1 is applicable to the new generation and the old generation, while CMS is only applicable to the old generation.
summary
This article briefly introduces the garbage collectors in the JVM, including serial collectors, parallel collectors, CMS collectors, and G1 collectors. They each have their pros and cons, and generally speaking, you need to perform a performance test based on the garbage collector based on your business, and then make a choice. The parameters that are often used when configuring the collector are given below:
-XX:+UseSerialGC: use serial collector in young and old generation
-XX:+UseParNewGC: use the parallel collector in the young generation
-XX:+UseParallelGC : The new generation uses parallel collection collectors and pays more attention to throughput
-XX:+UseParallelOldGC: use the parallel collection collector for the old generation
-XX:ParallelGCThreads: Set the number of threads used for garbage collection
-XX:+UseConcMarkSweepGC: The new generation uses the parallel collector, and the old generation uses the CMS+serial collector
-XX:ParallelCMSThreads: Set the number of CMS threads
-XX:+UseG1GC: Enable G1 garbage collector