There are 7 garbage collectors in the HotSpot virtual machine: Serial, ParNew, Parallel Scavenge, Serial Old, Parallel Old, CMS, G1.
The garbage collector is the specific implementation of the garbage collection algorithm (mark-sweep algorithm, copy algorithm, mark-sort algorithm, generational collection). The garbage collectors provided by different vendors and different versions of JVM may be very different. This section mainly introduces the garbage collector in the HotSpot virtual machine.
After JDK7/8, all collectors and combinations (connections) of the HotSpot virtual machine are as follows:
It can be seen from the above figure
New generation collectors: Serial, ParNew, Parallel Scavenge;
Old generation collectors: Serial Old, Parallel Old, CMS;
Whole heap collector: G1;
There is a connection between the two recyclers, indicating that they can be used together.
Parallel: refers to multiple garbage collection threads working in parallel, but the user thread is still in a waiting state at this time;
如ParNew、Parallel Scavenge、Parallel Old；
Concurrency: refers to the simultaneous execution of user threads and garbage collection threads (but not necessarily in parallel, and may be executed alternately);
The user program continues to run, while the garbage collector thread runs on another CPU;
Such as CMS, G1 (also parallel);
Various garbage collector application scenarios:
Serial collector
Serial (serial) garbage collector is the most basic collector with the longest history; before JDK1.3.1, it was the only choice for HotSpot new generation collection;
Application scenario : It is the default new generation collector of HotSpot in Client mode; there are also advantages over other collectors; Simple and efficient (compared to the single thread of other collectors); For environments limited to a single CPU, Serial collection There is no thread interaction (switching) overhead, and the highest single-threaded collection efficiency can be obtained; in the user's desktop application scenario, the available memory is generally not large (tens of M to one or two hundred M), and garbage can be completed in a short time. Collection (tens of MS to over a hundred MS), which is acceptable as long as it doesn't happen frequently.
Setting parameters : "-XX:+UseSerialGC": Add this parameter to explicitly use the serial garbage collector;
ParNew collector
The ParNew garbage collector is a multithreaded version of the Serial collector.
Application scenario : In Server mode, the ParNew collector is a very important collector, because apart from Serial, currently only it can work with the CMS collector; in a single CPU environment, it will not be better than the Serail collector effect, because of the thread interaction overhead.
Setting parameters
"-XX:+UseConcMarkSweepGC": After specifying the use of CMS, ParNew will be used as the new generation collector by default;
"-XX:+UseParNewGC": Force the use of ParNew;
"-XX:ParallelGCThreads": Specify the number of threads for garbage collection. The number of collection threads enabled by ParNew by default is the same as the number of CPUs;
Parallel Scavenge Collector
The Parallel Scavenge garbage collector is also called the Throughput Collector because it is closely related to throughput.
Application scenarios
High throughput is the goal, that is, reducing garbage collection time and allowing user code to get longer runtime;
When the application runs on multiple CPUs and does not have particularly high requirements for pause time, that is, the program mainly performs calculations in the background without much interaction with the user;
For example, those applications that perform batch processing, order processing, payroll, scientific computing;
Setting parameters
The Parallel Scavenge collector provides two parameters for precise control of throughput:
（A）"-XX:MaxGCPauseMillis"
Controls the maximum garbage collection pause time, the number of milliseconds greater than 0;
If MaxGCPauseMillis is set slightly smaller, the pause time may be shortened, but it may also reduce the throughput;
Because it may cause garbage collection to happen more frequently;
（B）"-XX:GCTimeRatio"
Set the ratio of garbage collection time to total time, an integer of 0<n<100;
GCTimeRatio is equivalent to setting the throughput size;
The ratio of garbage collection execution time to application execution time is calculated as:
1 / (1 + n)
For example, the option -XX:GCTimeRatio=19 sets the garbage collection time to 5% of the total time=1/(1+19);
The default value is 1%=1/(1+99), that is, n=99;
The time spent in garbage collection is the total time of young and old collections;
If the throughput target is not met, increase the memory size of the generation to maximize the time the user program runs;
In addition, there is a parameter worth paying attention to:
（C）、"-XX:+UseAdptiveSizePolicy"
After enabling this parameter, there is no need to manually specify some detailed parameters, such as:
The size of the new generation (-Xmn), the ratio of Eden to Survivor area (-XX: SurvivorRation), the age of the object promoted to the old generation (-XX: PretenureSizeThreshold), etc.;
The JVM will collect performance monitoring information according to the current system operation, and dynamically adjust these parameters to provide the most appropriate pause time or maximum throughput. This adjustment method is called GC adaptive adjustment strategy (GC Ergonomics);
Here is a recommended way:
1. Just set the memory data size (such as "-Xmx" to set the maximum heap);
2. Then use "-XX:MaxGCPauseMillis" or "-XX:GCTimeRatio" to set an optimization target for the JVM;
3. The adjustment of those specific details parameters is done by the JVM adaptively;
This is also an important difference between the Parallel Scavenge collector and the ParNew collector;
The above are all of the new generation, and the following will introduce the collectors of the old generation.
Serial Old collector
Serial Old is the old version of the Serial collector;
Application scenarios
Mainly used in Client mode;
In Server mode, there are two main purposes:
(A), in JDK1.5 and before, it can be used with Parallel Scavenge collector (JDK1.6 can be used with Parallel Old collector);
(B) As a backup plan for the CMS collector, it is used when Concurrent Mode Failure occurs in concurrent collection (detailed later);
Parallel Old collector
The Parallel Old garbage collector is the old version of the Parallel Scavenge collector; it was only available in JDK1.6;
JDK1.6 and later are used to replace the Serial Old collector of the old generation; especially in the case of Server mode and multiple CPUs;
In this way, in scenarios that focus on throughput and CPU resource sensitivity, there is a "powerful" application combination of Parallel Scavenge and Parallel Old collector;
Setting parameters
"-XX:+UseParallelOldGC": Specifies the use of Parallel Old collector;
CMS collector
Concurrent Mark Sweep (CMS) collector is also known as Concurrent Low Pause Collector or low-latency garbage collector;
Application scenarios
Scenarios with more interaction with users;
It is hoped that the system has the shortest downtime and pays attention to the response speed of the service;
In order to bring a better experience to users;
Such as applications on the server of common WEB and B/S systems;
Setting parameters
"-XX:+UseConcMarkSweepGC": Specifies to use the CMS collector;
3 Obvious Disadvantages of CMS Collectors
(A), very sensitive to CPU resources
Although concurrent collection does not suspend user threads, it will still cause the application to slow down and reduce the overall throughput because it occupies part of the CPU resources.
The default number of collection threads of CMS is = (number of CPUs + 3)/4;
When the number of CPUs is more than 4, the collection thread occupies more than 25% of the CPU resources, which may have a greater impact on the user program; when the number of CPUs is less than 4, the impact is greater and may not be acceptable.
Incremental concurrent collector:
In response to this situation, there has been an "incremental concurrent collector" (Incremental Concurrent Mark Sweep/i-CMS);
Similar to the idea of using preemption to simulate the multitasking mechanism, the collection thread and the user thread run alternately, reducing the running time of the collection thread;
But the effect is not ideal. After JDK1.6, it is no longer officially recommended for users to use it.
(B), Unable to process floating garbage, "Concurrent Mode Failure" may fail
1. Floating Garbage
During concurrent clearing, the garbage newly generated by the user thread is called floating garbage;
This makes it necessary to reserve a certain amount of memory space for concurrent clearing, and it cannot be collected when it is almost filled up in the old age like other collectors;
It should also be considered that CMS requires more space than other garbage collectors;
"-XX:CMSInitiatingOccupancyFraction": Set CMS reserved memory space;
JDK1.5 default value is 68%;
JDK1.6 becomes about 92%;
2. "Concurrent Mode Failure" failed
If the memory space reserved by the CMS cannot meet the needs of the program, a "Concurrent Mode Failure" failure will occur;
At this time, the JVM enables the backup plan: the Serail Old collector is temporarily enabled, which leads to another Full GC generation;
This cost is very large, so CMSInitiatingOccupancyFraction cannot be set too large.
(C), generate a lot of memory fragmentation
Since CMS is based on the "mark-sweep" algorithm, no compression is performed after clearing;
The previous "Java Virtual Machine Garbage Collection (2) Garbage Collection Algorithm" said when the "mark-sweep" algorithm was introduced:
The generation of a large number of non-contiguous memory fragments will lead to the inability to find enough contiguous memory when allocating large memory objects, so that another Full GC action needs to be triggered in advance.
Solution:
1、"-XX:+UseCMSCompactAtFullCollection"
Make the CMS not perform Full GC when the above situation occurs, but start the process of merging and sorting memory fragments;
However, the merging and sorting process cannot be concurrent, and the pause time will become longer;
It is enabled by default (but not performed, combined with the following CMSFullGCsBeforeCompaction);
2、"-XX:+CMSFullGCsBeforeCompaction"
Set how many times to perform a full GC without compression, and then perform a compaction;
In order to reduce the pause time of the consolidation process;
The default is 0, which means that Full GC is performed every time, and no compaction is performed;
Since the space is no longer continuous, CMS needs to use the available "free list" memory allocation method, which consumes more memory than the simple and practical "collision pointer" allocation;
G1 collector
G1 (Garbage-First) is a commercial collector that was launched only in JDK7-u4;
Application scenarios
Server-oriented applications, for machines with large memory and multiple processors;
The main application is to provide solutions for applications that require low GC latency and have large heaps;
For example: when the heap size is about 6GB or more, the predictable pause time can be less than 0.5 seconds;
Used to replace the CMS collector in JDK1.5;
Using G1 may be better than CMS in the following situations:
(1) More than 50% of the Java heap is occupied by active data;
(2) The frequency of object allocation or the frequency of age promotion varies greatly;
(3) The GC pause time is too long (longer than 0.5 to 1 second).
Is it necessary to use G1? Not necessarily:
If there is no problem with the current collector, don't rush to choose G1;
If the application pursues low pause, you can try to select G1;
Whether to replace the CMS requires actual scenario testing to know.
Setting parameters
"-XX:+UseG1GC": specifies the use of the G1 collector;
"-XX:InitiatingHeapOccupancyPercent": When the occupancy rate of the entire Java heap reaches the parameter value, the concurrent marking phase starts; the default is 45;
"-XX:MaxGCPauseMillis": Set the pause time target for G1, the default value is 200 milliseconds;
"-XX:G1HeapRegionSize": Set the size of each Region, ranging from 1MB to 32MB; the goal is to have about 2048 Regions in the smallest Java heap;