In the previous article, we covered common JVM garbage collection algorithms. Today, we will discuss HotSpot classic garbage collectors in detail.
First, the relationship between various classic collectors
1. The image shows the various collectors acting on different generations, and if there is a line between the two collectors, it indicates that they can be used together (this relationship is not static, due to the cost of maintenance and compatibility testing, The Serial + CMS and ParNew + Serial Old combinations were declared deprecated in JDK 8 and completely unsupported in JDK 9), and the area in which the collector is located indicates whether it belongs to a new generation collector or an Old generation collector.
2. Before introducing the individual features of these collectors, it is important to clarify one point: While carries on the comparison to the collector, but doesn’t come out in order to choose a best collector, although the garbage collector technology is improving, but until now is not the best collector, more do not exist “universal” collector, so we choose only the most suitable collector for specific applications.
It doesn’t take much argument to prove that the HotSpot VIRTUAL machine wouldn’t need to implement so many different collectors if there was a perfect collector that could be used universally in any situation.
Serial collector
1. Schematic diagram of Serial collector running
2, Serial collector introduction
(1) The Serial collector is the most basic and oldest collector and was once (prior to JDK 1.3.1) the only choice for the new generation of HotSpot VIRTUAL machine collectors.
(2) As you can guess from the name, this collector is a single-threaded collector that must suspend all other worker threads while garbage is collected until it is finished.
(3) The term “Stop The World” may sound cool, but this work is automatically initiated and completed by virtual machines in The background. It is unacceptable for many applications to Stop all The normal working threads of users without The user’s knowledge and control. Imagine if your computer stopped responding for five minutes every hour.
3. Application scenarios of the Serial collector
(1) so far, is still the HotSpot virtual Serial collector chance in client mode in the new generation collector, is superior to other places of the collector, which is simple and efficient (compared to other collectors single-threaded), for the limited memory resources environment, it is the smallest of all the extra memory consumption in the collector; For single-core processors or environments with a small number of processor cores, the Serial collector can achieve maximum single-thread collection efficiency by focusing on garbage collection because there is no overhead of thread interaction.
(2) in the user’s desktop application scenario, the memory allocated to the virtual machine management in general is not particularly big, collect YiLiangBaiZhao even with a few megabytes of Cenozoic (only refers to a new generation of memory used), garbage collection pauses can completely control in their teens and tens of milliseconds, up to more than one hundred milliseconds, as long as it’s not frequent collection, This pause time is perfectly acceptable to many users.
(3) Therefore, Serial collector is a good choice for virtual machines running in client mode
ParNew collector
1. Sketch of ParNew collector running
2. Introduction to the ParNew collector
The ParNew collector is essentially a multithreaded parallel version of the Serial collector, with all of the control parameters available to the Serial collector (for example:
– XX: SurvivorRatio,
– XX: PretenureSizeThreshold,
-xx: HandlePromotionFailure, etc.), collection algorithms, STW, object allocation rules, collection policies, and so on are all identical to Serial collectors, and the two collectors share a considerable amount of code in implementation.
3. The ParNew collector applies to scenarios
The ParNew collector does not offer much innovation over the Serial collector, except that it supports multi-threaded parallel collection, but it is the preferred new generation collector for HotSpot VMS running in server mode, especially legacy systems prior to JDK 7. One reason that has nothing to do with functionality or performance but is important is that it is currently the only one besides the Serial collector that works with the CMS collector.
The Avenge
Run the Parallel Scavenge collector
The Parallel Avenge collector
The Parallel Collector is a new generation collector. It is based on the mark-copy algorithm and the Parallel Collector. It is a multi-threaded collector that can collect in Parallel. The Parallel Exploiture is superficially similar to the ParNew Insane, so what’s so special about it?
The Parallel Insane collector is characterized by the differing focus of collectors such as the CMS insane, which is to minimize the pause time of user threads during garbage collection, while the Parallel Insane collector aims to achieve a manageable throughput.
Throughput is the ratio of the time the processor spends running user code to the total elapsed time of the processor.
Applicability of the Parallel Scavenge collector
If you don’t know how the collector works and it’s difficult to manually optimize it, use the Parallel Scavenge avenge in conjunction with an adaptive adjustment strategy and hand off the memory management tuning to the virtual machine may be a good choice.
Just set up the basic memory data (such as -xmx for maximum heap) and use the -xx: MaxGCPauseMillis parameter (more concerned with maximum pause time) or -xx: The GCTimeRatio (more throughput) parameter sets an optimization goal for the virtual machine, and the virtual machine adjusts the details.
The adaptive adjustment strategy is also an important feature of the Parallel Scavenge collector that distinguishes it from the ParNew collector. ParNew is the same as the Parallel Insane. ParNew is the Parallel Insane, enhanced to match the CMS ParNew insane.
Serial Old collector
1, Serial Old collector running schematic diagram (same as Serial schematic diagram)
2. Introduction to the Serial Old collector
Serial Old is an older version of the Serial collector, which is also a single-threaded collector using a mark-collation algorithm.
3. Applicable scenarios of the Serial Old collector
The main purpose of the Serial Old collector is also to be used by HotSpot virtual machines in client mode.
If in server mode, it may also serve two purposes:
Use the Parallel Scavenge avenge in JDK 5 and earlier versions.
(2) The other is used as a backup plan when the CMS collector fails and Concurrent Mode Failure occurs.
Parallel Old collector
Run the Parallel Old collector insane.
Parallel Old collector introduction
Parallel Old is an older version of the Parallel Avenge collector, supported by multiple threads for concurrent collection and implemented on a mark-collation algorithm.
The collector was only available in JDK 6, and prior to that, the newer generation of the Parallel Scavenge avenge would have had no choice but to Serial the Old collector. Other well-performing older collectors, such as CMS, do not work with it.
Due to the “drag” of the Serial collector on server application performance, the Parallel Collector is not necessarily an overall throughput maximizer. Similarly, because the single-threaded aged collection set cannot make full use of the parallel processing capability of the server’s multi-processors, the total throughput of this combination may not even be better than that of ParNew plus CMS in the operating environment with large memory space and relatively advanced hardware specifications.
3, Parallel Old collector applicable scenarios
The Parallel Avenge collector has been developed to match the insane with the Parallel Avenge collector. The Parallel Avenge collector can be used on applications where throughput is important or processor resources are scarce.
CMS collector
1. Schematic diagram of CMS collector operation
2. Introduction of CMS collector
The CMS (Concurrent Mark Sweep) collector is a collector whose goal is to obtain the shortest collection pause time.
At present, a large part of Java applications are concentrated on the server side of Internet websites or B/S system based on browsers. Such applications usually pay more attention to the response speed of services and hope that the system STW can be as short as possible to bring good interactive experience to users. The CMS collector is a good fit for such applications.
As the name (which includes “Mark Sweep”) suggests, the CMS collector is based on a mark-sweep algorithm, which is a bit more complex than the previous collectors.
The whole process is divided into four steps, including: 1) CMS Initial Mark
Have the STW; The initial tag simply marks the objects that GCRoots can be directly associated with, which is fast.
2) CMS Concurrent Mark
The concurrent marking phase is the process of traversing the entire object graph from the directly associated object of GC Roots. This process takes a long time but does not require the user thread to pause and can be run concurrently with the GC thread.
3) Re-marking (CMS Remark)
Have the STW; The re-marking phase is to correct the marking record of the part of the object whose marking changes due to the continued operation of the user program during concurrent marking. Adopt three-color marking algorithm and incremental update to avoid missing marks.
CMS Concurrent sweep
Cleanup removes dead objects judged by the marking phase, which can be executed concurrently with the user thread because there is no need to move live objects.
3. Disadvantages of the CMS collector
(1) THE CMS collector is very sensitive to processor resources.
(2) Because the CMS collector cannot handle “Floating Garbage,” it is possible that a “con-current Mode Failure” will result in another Full STW GC, leaving Serial Old to do the collection. Floating garbage is garbage generated when marked and cleaned concurrently.
(3) The generation of large amounts of space debris. When there is too much space debris, the allocation of large objects will cause a lot of trouble. It is often the case that there is still a lot of free space in the old years, but there is not enough contiguous space to allocate the current object, and you have to trigger a Full GC in advance.
Garbage First
1. Schematic diagram of G1 collector partitioning
E: Eden area
S: Survivor area
H: Humongous (large objects)
2. Operation diagram of G1
3. Introduction of G1 collector
All other collectors prior to the G1 collector, including the CMS, targeted garbage collection at either the entire Minor, Major, or Full Java heap. G1, however, breaks out of this trap. It can collect any part of the heap memory to form a Collection Set (generally referred to as CSet). The measurement standard is no longer the generation to which it belongs, but the memory that stores the most garbage and has the largest Collection benefit.
The region-based heap memory layout pioneered by G1 is key to its garbage-first goal. While G1 is still designed to follow the generational collection theory, its heap memory layout is very different from that of previous G1 collectors: G1 no longer insists on a fixed size and a fixed number of generational regions, but divides the continuous Java heap into multiple independent regions of equal size. Each Region can act as the Eden space of the new generation, Survivor space, or old chronospace as required. The collector can apply different strategies to regions that play different roles, so that both newly created objects and old objects that have survived multiple collections for a while can be collected well.
While G1 still retains the concept of Cenozoic and oldene, Cenozoic and oldene are no longer fixed, but rather dynamic collections of a series of regions that do not need to be continuous. The G1 collector is able to model predictable pause times because it uses regions as the smallest unit of a single collection, that is, each collection of memory is an integer multiple of Region size, so that it can systematically avoid all-region garbage collection across the entire Java heap.
A more specific approach is to have the G1 collector track the “value” of garbage accumulation in each Region, which is the amount of space collected and the experience of how long it takes to collect, and then maintain a list of priorities in the background, each time according to the user set the allowable collection pause time (using the parameter -xx: MaxGCPauseMillis specifies, the default is 200 milliseconds), which prioritises regions that benefit most from collecting value, hence the name “Garbage First”.
4. Disadvantages of the G1 collector
G1 has a higher memory footprint than CMS, both for garbage collection and for additional execution load at runtime
5. Application scenarios of G1 collector
CMS’s performance on the application in the memory at present big probability will be better than the G1, while the G1 in the large memory application for the most part can exert its advantages and the disadvantages of the Java heap capacity balance between the 6 gb to 8 gb, usually, of course, this is not absolute, different applications need to actual status of testing to come to the conclusion that the most appropriate, As HotSpot developers continue to optimize G1, the comparison will continue to tilt in G1’s favor.
In general, HotSpot’s garbage collector is progressing along with the development of memory. In the early tens of megabytes of memory, Serial+Serial Old single-thread collection is enough. However, when the memory reaches several hundred megabytes, it has to use PS+PO multi-threaded GC thread to collect; When memory reaches several gigabytes, multithreading is too busy to come over, you have to use concurrent CMS+ParNew collector; When it comes to tens of gigabytes of memory, the old STW, which does a new generation or old generation or whole heap collection every GC, can’t stand it.
Most production environments currently use JDK8, and if not tuned, the PS+PO collector is used by default; However, when it comes to tuning, CMS and G1 will be chosen. If there is a large amount of memory (more than 10 GIGABytes), G1 is the best choice, and if there is a small amount of memory (several gigabytes), CMS can be considered.
However, as stated at the beginning of this article, if there were a perfect collector that could be used universally in any situation, the HotSpot VIRTUAL machine would not need to implement so many different collectors.
There is only the best collector, there is no best collector.