Part 1 of JVM_17_Garbage Collector_Silicon Valley

1-GC classification and performance indicators

Garbage Collector Overview

The garbage collector is not specified too much in the specification, and it can be implemented by different vendors and different versions of the JVM.
Since the JDK version is in a high-speed iteration process, Java has developed many GC versions so far.
Analyzing garbage collectors from different angles, GC can be divided into different types.

New features of different versions of Java

Grammatical level: Lambda expressions, switch, automatic unboxing and boxing, enum, generics
API level: Stream API, new date and time, Optional, String, collection framework
Underlying optimization: JVM optimization, GC changes, meta space, static domain, string constant pool, etc.

garbage collector classification

According to the number of threads (number of garbage collection threads), it can be divided into serial garbage collector and parallel garbage collector.

Serial collection means that only one CPU is allowed to perform garbage collection operations at the same time period, and the worker thread is suspended until the garbage collection work is completed.
- In situations where the hardware platform is not particularly superior, such as a single CPU processor or a small application memory, the performance of the serial collector can exceed that of the parallel collector and the concurrent collector. Therefore, serial recycling is applied by default to the JVM in the Client mode of the client
- On CPUs with strong concurrency capabilities, the pause time generated by the parallel collector is shorter than that of the serial collector
Contrary to serial collection, parallel collection can use multiple CPUs to perform garbage collection at the same time, thus improving the throughput of the application, but parallel collection is still the same as serial collection, adopting exclusive mode and using the "Stop-the-World" mechanism .

According to the working mode, it can be divided into concurrent garbage collector and exclusive garbage collector.

The concurrent garbage collector works alternately with application threads to minimize application pause times.
Once the exclusive garbage collector (Stop the World) runs, it stops all user threads in the application until the garbage collection process is completely over.

According to the fragmentation method, it can be divided into compression garbage collector and non-compression garbage collector.

The compact garbage collector will compress and organize the surviving objects after the collection is completed, and eliminate the fragments after collection. Reallocate object space using pointer collision
The non-compressed garbage collector does not perform this step, and allocates object space using the free list

According to the working memory interval, it can be divided into young generation garbage collector and old generation garbage collector.

Evaluate GC Performance Metrics

index

Throughput: the ratio of the time spent running user code to the total running time (total running time = program running time + memory recovery time)
Garbage Collection Overhead: The complement of throughput, the ratio of time spent in garbage collection to total runtime.
Pause time: The time during which the program's worker threads are suspended while performing garbage collection.
Collection Frequency: How often collection operations occur relative to the execution of the application.
Memory occupation: the memory size occupied by the Java heap area.
Fast: The time it takes for an object to be reclaimed from its birth.
Throughput, pause time, and memory usage together form an "impossible triangle". The overall performance of the three will get better and better as technology advances. An excellent collector usually satisfies at most two of them at the same time.
Among these three items, the importance of pause time is becoming increasingly prominent. Because with the development of hardware, more memory usage is more and more tolerable, and the improvement of hardware performance also helps to reduce the impact of the collector on the application when it is running, that is, to increase the throughput. The expansion of the memory has a negative effect on the delay.
To put it simply, there are two main points:
- throughput
- pause time

throughput

Throughput is the ratio of the time the CPU spends running user code to the total time consumed by the CPU, that is, throughput = running user code time/(running user code time + garbage collection time)
- For example, if the virtual machine runs for 100 minutes in total, and garbage collection takes 1 minute, then the throughput is 99%.
In this case, the application can tolerate higher pause times, so high-throughput applications have a longer time base, and fast response is not a concern
Throughput priority means that the STW time is the shortest per unit time: 0.2+0.2=0.4

pause time

"Pause time" refers to the state where the application thread is suspended for a period of time to allow the GC thread to execute.
- For example, a pause time of 100 ms during GC means that no application threads are active during this 100 ms period
The priority of pause time means that the time of single STW is as short as possible: 0.1+0.1+0.1+0.1+0.1=0.5, but the total GC time may be longer

Throughput vs Pause Time

High throughput is better because it gives the end user of the application the impression that only the application threads are doing "productive" work. Intuitively, the higher the throughput, the faster the program will run.
Low pause time (low latency) is better, but from the end user's point of view, it is always bad for an application to be suspended, whether it is GC or other reasons. Depending on the type of application, sometimes even a brief 200ms pause can interrupt the end user experience. Therefore, it is very important to have a low pause time, especially for an interactive application (that is, a scene with more user interaction).
Unfortunately "high throughput" and "low pause time" are a pair of competing goals (contradiction).
- Because if you choose to prioritize throughput, you must reduce the execution frequency of memory recovery , but this will cause the GC to take a longer pause time to perform memory recovery.
- On the contrary, if you choose the principle of low latency priority, then in order to reduce the pause time of each execution of memory recovery, you can only perform memory recovery frequently, but this in turn causes the reduction of young generation memory and leads to the reduction of program throughput. decline.
When designing (or using) a GC algorithm, we must determine our goals: a GC algorithm may only aim at one of two goals (i.e. only focus on maximum throughput or minimum pause time), or try to find a combination of both compromise.
Now Standard: Reduce Pause Time Where Maximum Throughput Prioritizes

2- Overview of different garbage collectors

The garbage collection mechanism is a signature capability of Java, which greatly improves development efficiency. This is of course also a hot spot for interviews.
So, what are the common garbage collectors in Java?

History of the Garbage Collector

With a virtual machine, a garbage collection mechanism is definitely needed. This is Garbage Collection, and the corresponding product is called Garbage Collector.

In 1999, the Serial GC came with JDK1.3.1, which is the first GC. The ParNew garbage collector is a multi-threaded version of the Serial collector
On February 26, 2002, Parallel GC and Concurrent Mark Sweep GC were released together with JDK1.4.2·
Parallel GC becomes the default GC of HotSpot after JDK6.
In 2012, in the JDK1.7u4 version, G1 is available.
In 2017, G1 became the default garbage collector in JDK9 to replace CMS.
In March 2018, parallel full garbage collection by the G1 garbage collector in JDK10, enabling parallelism to improve worst-case latency.
In September 2018, JDK11 was released. Introduced the Epsilon garbage collector, also known as the "No-Op (no operation)" collector. At the same time, introduce ZGC: scalable low-latency garbage collector (Experimental)
In March 2019, JDK12 was released. Enhanced G1 to automatically return unused heap memory to the operating system. At the same time, introduce Shenandoah GC: GC with low pause time (Experimental).
In September 2019, JDK13 was released. Enhance ZGC to automatically return unused heap memory to the operating system.
In March 2020, JDK14 was released. Remove CMS garbage collector. Extend the application of ZGC on macOS and Windows

7 classic garbage collectors

Serial collector: Serial, Serial old
Parallel collectors: ParNew, Parallel Scavenge, Parallel old
Concurrent collectors: CMS, G1

There is a line between the two collectors, indicating that they can be used together:
- Serial/Serial old
- Serial/CMS (JDK9 obsolete)
- ParNew/Serial Old (JDK9 obsolete)
- ParNew/CMS
- Parallel Scavenge/Serial Old (scheduled to be obsolete)
- Parallel Scavenge/Parallel Old
- G1
Among them, Serial Old is used as a backup plan for "Concurrent Mode Failure" failure of CMS.
(Red dotted line) Due to the cost of maintenance and compatibility testing, the two combinations of Serial+CMS and ParNew+Serial Old were declared obsolete in JDK 8 (JEP173), and the support of these combinations was completely canceled in JDK9 (JEP214 ), i.e. remove.
(Green dotted line) JDK14: Deprecate the combination of Parallel Scavenge and Serial Old GC (JEP366)
(cyan dotted line) JDK14: remove CMS garbage collector (JEP363)
Why are there many collectors, one is not enough? Because Java has many usage scenarios, such as mobile terminals, servers, etc. Therefore, it is necessary to provide different garbage collectors for different scenarios to improve the performance of garbage collection.
Although we will compare various collectors, it is not to pick a best collector. There is no one-size-fits-all perfect collector that is applicable in any scenario, let alone a universal collector. So what we choose is only the most suitable collector for the specific application .

View the default garbage collector

-XX:+PrintCommandLineFlags : View command line related parameters (including the garbage collector used)
Use the command line command: jinfo -flag related garbage collector parameters process ID

jinfo -flag UseParallelGC 40756
jinfo -flag UseG1GC 40756

3-Serial collector: serial collection

Serial collector: serial collection

The Serial collector is the most basic and oldest garbage collector. Before JDK1.3, the only option to recycle the new generation.
The Serial collector is used as the default new generation garbage collector in Client mode in HotSpot.
The Serial collector uses the copy algorithm, serial collection, and "Stop-the-World" mechanism to perform memory collection .
In addition to the young generation, the Serial collector also provides the Serial Old collector for performing old generation garbage collection. The Serial old collector also uses the serial recycling and "Stop the World" mechanism, but the memory recycling algorithm uses the mark-compression algorithm .
- Serial Old is the default old generation garbage collector running in Client mode.
- Serial Old has two main purposes in Server mode: ①Cooperate with the new generation of Parallel Scavenge ②As a backup garbage collection scheme for the old generation CMS collector

This collector is a single-threaded collector, "single-threaded" means: it will only use one CPU (serial) or one collection thread to complete garbage collection. More importantly, when it is collecting garbage, all other worker threads must be suspended until it is collected (Stop The World)

Advantages of the Serial Collector

Advantages: Simple and efficient (compared to the single-threaded performance of other collectors). For an environment limited to a single CPU, the Serial collector has no thread interaction overhead, so concentrating on garbage collection can naturally obtain the highest single-threaded collection efficiency. A virtual machine running in Client mode is a good choice.
In the user's desktop application scenario, the available memory is generally not large (tens of MB to one or two hundred MB), and garbage collection can be completed in a relatively short period of time (tens of ms to more than a hundred ms). As long as it does not happen frequently, use A serial collector is acceptable.
In the HotSpot virtual machine, use the -XX:+UseSerialGC parameter to specify that both the young generation and the old generation use the serial collector.
- It is equivalent to using Serial GC in the new generation, and using Serial Old GC in the old generation

C:\Users\86156>jinfo -flag UseG1GC 18688
-XX:-UseG1GC

C:\Users\86156>jinfo -flag UseSerialGC 18688
-XX:+UseSerialGC

Summarize

This kind of garbage collector is known to everyone, and serial ones are no longer used. And it can only be used on a limited single-core CPU. It's not single core anymore.
For highly interactive applications, this kind of garbage collector is unacceptable. Generally, serial garbage collectors are not used in Java Web applications.

4-ParNew collector: Parallel collection

If Serial GC is a single-threaded garbage collector in the young generation, then the ParNew collector is a multi-threaded version of the Serial collector.
- Par is the abbreviation of Parallel, New: can only handle the new generation
There is almost no difference between the two garbage collectors except that the ParNew collector performs memory collection in parallel . The ParNew collector also uses the replication algorithm and " Stop-the-World " mechanism in the young generation .
ParNew is the default garbage collector for the new generation of many JVMs running in Server mode.

For the new generation, the number of collections is frequent, and the use of parallel methods is efficient.
For the old generation, the number of recycling is small, and the serial method is used to save resources. (The CPU needs to switch threads in parallel, and serial can save the resources of switching threads)

Comparison of ParNew collector and Serial collector

Since the ParNew collector is based on parallel recycling, can it be concluded that the recycling efficiency of the ParNew collector will be more efficient than Serial collection in any scenario?

The ParNew collector runs in a multi-CPU environment. Because it can make full use of physical hardware resources such as multiple CPUs and cores, it can complete garbage collection more quickly and improve the throughput of the program.
But in a single CPU environment, the ParNew collector is not more efficient than the Serial collector . Although the Serial collector is based on serial recycling, since the CPU does not need to switch tasks frequently, it can effectively avoid some additional overhead generated during multi-thread interaction.
Because apart from Serial, currently only ParNew GC can work with the CMS collector.

Set up the ParNew garbage collector

In the program, developers can manually specify to use the ParNew collector to perform memory recovery tasks through the option "-XX:+UseParNewGC". It means that the young generation uses the parallel collector and does not affect the old generation.
-XX:ParallelGCThreads limits the number of threads, and the same number of threads as the CPU data is enabled by default.

5-Parallel collector: throughput priority

Parallel Scavenge Collector: Prioritize Throughput

In addition to the ParNew collector in HotSpot's young generation, which is based on parallel recycling, the Parallel Scavenge collector also uses the replication algorithm, parallel recycling, and the "Stop the World" mechanism .
So is the emergence of the Parallel collector superfluous?
- Unlike the ParNew collector, the goal of the Parallel Scavenge collector is to achieve a controllable throughput (Throughput), which is also known as a throughput-first garbage collector.
- The adaptive adjustment strategy is also an important difference between Parallel Scavenge and ParNew. (dynamically adjust memory allocation to achieve an optimal throughput or low latency)
High throughput can use CPU time efficiently and complete the calculation tasks of the program as soon as possible. It is mainly suitable for tasks that operate in the background without much interaction . Therefore, it is commonly used in server environments. For example, those applications that perform batch processing, order processing, payroll, scientific computing.
The Parallel collector provides a Parallel Old collector for garbage collection in the old age in JDK1.6, which is used to replace the Serial Old collector in the old age.
The Parallel Old collector uses a mark-compression algorithm , but it is also based on parallel collection and the "Stop-the-World" mechanism.

In the application scenario where program throughput is prioritized, the combination of the Parallel collector and the Parallel Old collector has very good memory recovery performance in server mode.
In Java8, this garbage collector is the default.

Parallel Scavenge collector parameter settings

-XX:+UseParallelGC manually specifies that the young generation uses the Parallel parallel collector to perform memory recovery tasks.
-XX:+UseParallelOldGC : Manually specify that the old generation is to use the parallel collection collector.
- Applicable to the new generation and the old generation respectively
- The above two parameters apply to the new generation and the old generation respectively. By default jdk8 is enabled. If one is enabled by default, the other will also be enabled. (mutual activation)
-XX:ParallelGCThreads : Set the number of threads for the young generation parallel collector. In general, it is best to be equal to the number of CPUs to avoid excessive number of threads affecting garbage collection performance.
1. By default, when the number of CPUs is less than 8, the value of ParallelGCThreads is equal to the number of CPUs.
2. When the number of CPUs is greater than 8, the value of ParallelGCThreads is equal to 3+[5*CPU_Count]/8]
-XX:MaxGCPauseMillis sets the maximum pause time of the garbage collector (ie STW time). The unit is milliseconds.
1. In order to control the pause time within XX:MaxGCPauseMillis as much as possible, the collector will adjust the Java heap size or some other parameters when working.
2. For users, the shorter the pause time, the better the experience. But on the server side, we focus on high concurrency and overall throughput. So the server side is suitable for Parallel, for control.
3. Use this parameter with caution .
-XX:GCTimeRatio The ratio of garbage collection time to the total time, which is equal to 1 / (N+1), used to measure the throughput.
1. The value range is (0, 100). The default value is 99, which means that the garbage collection time does not exceed 1%.
2. There is a certain contradiction with the previous -XX:MaxGCPauseMillis parameter. The longer the STW pause time, the Radio parameter will easily exceed the set ratio.
-XX:+UseAdaptiveSizePolicy sets the Parallel Scavenge collector to have an adaptive adjustment strategy
- In this mode, parameters such as the size of the young generation, the ratio of Eden to Survivor, and the age of objects promoted to the old generation will be automatically adjusted to reach a balance between heap size, throughput, and pause time.
- In situations where manual tuning is difficult, you can directly use this adaptive method to specify only the maximum heap, target throughput (GCTimeRatio) and pause time (MaxGCPauseMillis) of the virtual machine, and let the virtual machine complete the tuning work by itself.

6-CMS collector: low latency

CMS Recycler

During the JDK1.5 period, Hotspot launched a garbage collector that can be considered as an epoch-making significance in strong interactive applications (that is, references dealing with users) : CMS (Concurrent-Mark-Sweep) collector, this collector It is the first real concurrent collector in the HotSpot virtual machine, and it is the first time that the garbage collection thread and the user thread work simultaneously.
The focus of the CMS collector is to minimize the pause time of user threads during garbage collection. The shorter the pause time (low latency), the more suitable for programs that interact with users, and good response speed can improve user experience.
- At present, a large part of Java applications are concentrated on the server side of Internet websites or B/S systems. Such applications pay special attention to the response speed of services, hoping that the system pause time will be the shortest, so as to bring better experience to users . The CMS collector is very suitable for the needs of this type of application.
The garbage collection algorithm of CMS uses the mark-sweep algorithm, and will also "Stop-the-World"
Unfortunately, as a collector of the old generation, CMS cannot work with the new generation collector Parallel Scavenge that already exists in JDK1. When using CMS to collect the old generation, the new generation can only choose one of the ParNew or Serial collectors.
Before the advent of G1, CMS was still widely used. To this day, there are still many systems using CMS GC.

How CMSs work

The whole process of CMS is more complicated than the previous collector. The whole process is divided into 4 main stages, namely, the initial marking phase, the concurrent marking phase, the re-marking phase and the concurrent clearing phase.

Initial mark (Initial-Mark) stage: In this stage, all worker threads in the program will have a short pause due to the "Stop-the-World" mechanism. The main task of this stage is only to mark that GC Roots can directly associated with the object . All application threads that were suspended will be resumed once the marking is complete. Since the directly associated objects are relatively small, the speed here is very fast .
Concurrent-Mark stage: Traversing the entire object graph from the directly associated objects of GC Roots , this process does not need to pause user threads , and can run concurrently with garbage collection threads.
Remark (Remark) phase: Since in the concurrent marking phase, the working thread of the program will run concurrently or cross-running with the garbage collection thread, so in order to correct the part of the objects whose marking changes due to the continued operation of the user program during the concurrent marking period Marking records , the pause time of this phase is usually slightly longer than the initial marking phase, but it is also much shorter than the concurrent marking phase.
Concurrent-Sweep stage: This stage cleans up and deletes the dead objects judged by the marking stage, and releases memory space . Since there is no need to move surviving objects, this stage can also be concurrent with user threads.

CMS Low Latency Analysis

Although the CMS collector uses concurrent recycling (non-exclusive), it still needs to implement the "Stop-the-World" mechanism to suspend the worker threads in the program during the two stages of its initialization mark and mark again, but the pause time does not It won't be too long, so it can be said that all current garbage collectors can't do "Stop-the-World" at all, just shorten the pause time as much as possible.

Since the most time-consuming concurrent marking and concurrent sweeping phases do not require pausing work, the overall collection is low-pause .

In addition, since the user thread is not interrupted during the garbage collection phase, it should also ensure that the application user thread has enough memory available during the CMS recycling process . Therefore, the CMS collector cannot wait until the old generation is almost completely filled up like other collectors, but when the heap memory usage reaches a certain threshold, it starts to recycle to ensure that the application is in the process of CMS work. There is still enough space for the application to run. If the memory reserved during the operation of the CMS cannot meet the needs of the program, a " Concurrent Mode Failure " failure will occur. At this time, the virtual machine will start a backup plan: temporarily start the Serial Old collector to re-collect the garbage in the old age, so that the pause time It is very long.

The garbage collection algorithm of the CMS collector uses a mark-clear algorithm , which means that after each memory recovery is performed, the memory space occupied by the useless objects that perform memory recovery is very likely to be some discontinuous memory blocks. Inevitably there will be some memory fragmentation . Then CMS will not be able to use the Bump the Pointer technology when allocating memory space for new objects, but can only select the free list (Free List) to perform memory allocation.

Some people think that since Mark Sweep will cause memory fragmentation, why not change the algorithm to Mark Compact?

The answer is actually very simple, because when cleaning concurrently, if you use Compact to organize the memory, how can the memory used by the original user thread be used? To ensure that the user thread can continue to execute, the premise is that the resources it runs on are not affected. Mark Compact is more suitable for use in the "stop the world" scenario

Advantages of CMS

concurrent collection
low latency

Disadvantages of CMS

Memory fragmentation will occur , resulting in insufficient space available to user threads after concurrent clearing. In the case that large objects cannot be allocated, Full GC has to be triggered in advance.
The CMS collector is very sensitive to CPU resources. In the concurrency stage, although it will not cause users to pause, it will slow down the application and reduce the total throughput because it occupies a part of the thread.
The CMS collector cannot handle floating garbage . There may be a "Concurrent Mode Failure" failure that causes another Full GC to occur. In the concurrent marking phase, since the program's worker threads and garbage collection threads are running at the same time or cross-running, if new garbage objects are generated during the concurrent marking phase, CMS will not be able to mark these garbage objects, which will eventually lead to these newly generated garbage objects. Garbage objects are not recovered in time , so the memory space that has not been recovered can only be released when the next GC is executed.

CMS parameter configuration

-XX:+UseConcMarkSweepGC : Manually specify to use the CMS collector to perform memory recovery tasks.

After this parameter is turned on, -XX:+UseParNewGC will be turned on automatically. That is: the combination of ParNew (Young area) + CMS (Old area) + Serial Old (Old area alternative).
-XX:CMSInitiatingOccupanyFraction : Set the threshold of heap memory usage, once the threshold is reached, recycling will start.

The default value of JDK5 and previous versions is 68, that is, when the space usage rate of the old generation reaches 68%, a CMS recycling will be performed. The default value of JDK6 and above is 92%
If the memory growth is slow, you can set a slightly larger value. A larger threshold can effectively reduce the trigger frequency of CMS, and reduce the number of old generation recycling can significantly improve application performance. Conversely, if the application's memory usage grows rapidly, this threshold should be lowered to avoid triggering the old serial collector frequently. Therefore , this option can effectively reduce the number of executions of Full GC .

-XX:+UseCMSCompactAtFullCollection : Used to specify that the memory space should be compacted after the Full GC is executed, so as to avoid memory fragmentation. However, since the memory compression and sorting process cannot be executed concurrently, the problem is that the pause time becomes longer.
-XX:CMSFullGCsBeforeCompaction : Set how many times Full GC is performed to compress the memory space.
-XX:ParallelCMSThreads : Set the number of CMS threads.

The number of threads started by CMS by default is (ParallelGCThreads + 3) / 4. ParallelGCThreads is the number of threads of the young generation parallel collector, which can be regarded as the maximum number of threads supported by the CPU. When CPU resources are tight, the performance of the application during the garbage collection phase may be very poor due to the impact of the CMS collector thread.

summary

HotSpot has so many garbage collectors, so if someone asks, what is the difference between the three GCs, Serial GC, Parallel GC, and Concurrent Mark Sweep GC?

Please remember the password:

If you want to minimize the use of memory and parallel overhead, please choose Serial GC;

If you want to maximize the throughput of the application, please choose Parallel GC;

If you want to minimize GC interruptions or pause times, choose CMS GC.

Changes to the CMS in subsequent releases of the CMS

New feature of JDK9: CMS is marked as Deprecate (JEP291)
- If the parameter -XX is used for the HotSpot virtual machine of JDK 9 and above:
  
  +UseConcMarkSweepGC to enable the CMS collector, the user will receive a warning message that the CMS will be deprecated in the future.
New feature of JDK14: delete CMS garbage collector (JEP363)
- The CMS garbage collector has been removed. If -XX:UseConcMarkSweepGC is used in JDK14, JCM will not report an error, but will only give a warning message, but will not exit. The JVM will automatically fall back to start the JVM in the default GC mode

7-G1 Collector: Regional Generation

Since we already have the previous powerful GC, why release Garbage First (G1) GC?

The reason is that the business of the application program is becoming larger and more complex, and there are more and more users. Without GC, the application program cannot be guaranteed to run normally, and the GC of STW often cannot keep up with the actual demand, so it will continue to Try to optimize the GC.
The G1 (Garbage-First) garbage collector is a new garbage collector introduced after Java7 update4, and is one of the most cutting-edge achievements in the development of today's collector technology.
At the same time, in order to adapt to the ever-expanding memory and the increasing number of processors , the pause time is further reduced, while taking into account good throughput.
The official goal set for G1 is to obtain the highest possible throughput while the delay is controllable, so it takes on the heavy responsibility and expectation of a "full-featured collector" .

Why is it called Garbage First (G1)?

Because G1 is a parallel collector, it divides the heap memory into many irrelevant regions (Regions) (physically discontinuous). Use different Regions to represent Eden, Survivor 0, Survivor 1, Old Age, etc.
The G1 GC programmatically avoids region-wide garbage collection on the entire Java heap. G1 tracks the value of garbage accumulation in each Region (the size of the space obtained by recycling and the experience value of the time required for recycling), maintains a priority list in the background, and gives priority to recycling the Region with the highest value according to the allowed collection time each time .
Since this approach focuses on reclaiming the region with the largest amount of garbage (Region), we give G1 a name: Garbage First.
G1 (Garbage-First) is a garbage collector for server-side applications. It is mainly aimed at machines equipped with multi-core CPUs and large-capacity memory . It meets the GC pause time with a high probability and also has high-throughput performance characteristics. .
It was officially launched in JDK1.7 version, and the Experimental logo was removed. It is the default garbage collector after JDK9 , replacing the CMS collector and the combination of Parallel+Parallel Old. It is officially called "full-featured garbage collector" by Oracle .
At the same time, CMS has been marked as deprecated in JDK9. G1 is not the default garbage collector in JDK8 , you need to use -XX:+UseG1GC to enable it.

Advantages of the G1 Collector

Compared with other GC collectors, G1 uses a brand-new partition algorithm, and its characteristics are as follows:

Both parallel and concurrent
- Parallelism: During G1 recycling, multiple GC threads can work simultaneously to effectively utilize multi-core computing power. At this point the user thread STW
- Concurrency: G1 has the ability to execute alternately with the application, and part of the work can be executed at the same time as the application. Therefore, generally speaking, the application will not be completely blocked during the entire recycling phase.
Generational collection
- From the perspective of generation, G1 is still a generational garbage collector , which distinguishes the young generation from the old generation. The young generation still has the Eden area and the Survivor area. But from the perspective of the heap structure, it does not require the entire Eden area, the young generation or the old generation to be continuous, and it no longer insists on a fixed size and a fixed number.
- Divide the heap space into several regions (Regions), which contain the logical young generation and old generation .
- Unlike previous types of collectors, it takes care of both the young generation and the old generation at the same time . Compared with other collectors, either work in the young generation or work in the old generation;

The generation of G1 is no longer as follows

[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-KE7306Na-1663494341085) (C:\Users\86156\AppData\Roaming\Typora\typora-user-images\ image-20220917220557144.png)]

Instead:

spatial integration
- CMS: "mark-clear" algorithm, memory fragmentation, defragmentation after several GCs.
- G1 divides memory into regions. The recovery of memory is based on the region as the basic unit. There is a copy algorithm between Regions, but it can actually be regarded as a mark-compression (Mark-Compact) algorithm as a whole . Both algorithms can avoid memory fragmentation. This feature is conducive to the long-running of the program. When allocating large objects, the next GC will not be triggered in advance because no continuous memory space can be found. Especially when the Java heap is very large, the advantages of G1 are more obvious.
Predictable pause time model (ie: soft real-time)

This is another major advantage of G1 over CMS. In addition to pursuing low pauses, G1 can also establish a predictable pause time model, allowing users to clearly specify that within a time segment of M milliseconds, the time spent in garbage collection The time on must not exceed N milliseconds.

Due to partitioning, G1 can only select some areas for memory recovery, which reduces the scope of recovery, so the occurrence of global pauses can also be better controlled.
G1 tracks the value of garbage accumulation in each Region (the size of the space obtained by recycling and the experience value of the time required for recycling), maintains a limited list in the background, and gives priority to recycling the Region with the highest value according to the allowed collection time each time . It ensures that the G1 collector can obtain the highest possible collection efficiency within a limited time .
Compared with CMS GC, G1 may not be able to achieve the delay pause of CMS in the best case, but the worst case is much better.

Disadvantages of G1 Recycling

Compared with CMS, G1 is not omni-directional, but overwhelming. For example, during the running of user programs, G1 is higher than CMS in terms of the memory footprint (Footprint) generated by garbage collection and the additional execution load (Overload) when the program is running.

From experience, the performance of CMS in small-memory applications is likely to be better than G1, and G1 will play its advantages in large-memory applications. The balance point is between 6-8GB.

G1 parameter setting

-XX:+UseG1GC : Manually specify to use the G1 garbage collector to perform memory recovery tasks
-XX:G1HeapRegionSize : Set the size of each Region. The value is a power of 2, the range is between 1MB and 32MB, and the goal is to divide about 2048 regions according to the minimum Java heap size. The default is 1/2000 of the heap memory.
-XX:MaxGCPauseMillis : Set the expected maximum GC pause time indicator, and the JVM will try its best to achieve it, but it is not guaranteed to be achieved. The default value is 200ms
-XX:+ParallelGCThread : Set the value of the number of GC threads when STW. set up to 8
-XX:ConcGCThreads : Set the number of threads for concurrent marking. Set n to about 1/4 of the number of parallel garbage collection threads (ParallelGcThreads).
-XX:InitiatingHeapOccupancyPercent : Sets the Java heap occupancy threshold for triggering concurrent GC cycles. If this value is exceeded, GC is triggered. The default value is 45.

Common operation steps of G1 recycler

The design principle of G1 is to simplify JVM performance tuning. Developers only need three simple steps to complete the tuning:

Step 1: Turn on the G1 garbage collector

Step 2: Set the maximum memory of the heap

Step 3: Set the maximum pause time

G1 provides three garbage collection modes: YoungGC, Mixed GC and Full GC, which are triggered under unused conditions.

Applicable scenarios of the G1 collector

For server-side applications, for machines with large memory and multiple processors. (not surprising performance on normal sized heaps)
The most important application is to provide solutions for applications that require low GC latency and have a large heap;
For example: when the heap size is about 6GB or larger, the predictable pause time can be less than 0.5 seconds; (G1 cleans up a part of the region instead of all the incremental cleanup each time to ensure that the pause time of each GC will not exceed long).
Used to replace the CMS collector in JDK1.5; in the following cases, using G1 may be better than CMS:
- More than 50% of the Java heap is occupied by active data;
- Object allocation frequency or age promotion frequency varies greatly;
- GC pauses are too long (longer than 0.5 to 1 second)
Among the HotSpot garbage collectors, except G1, other garbage collectors use the built-in JVM thread to perform GC multi-threaded operations, while G1 GC can use application threads to undertake background GC work, that is, when the JVM GC thread processing speed When slow, the system invokes application threads to help speed up the garbage collection process.

Partition Region

Partition Region: Divide into zero

When using the G1 collector, it divides the entire Java heap into about 2048 independent Region blocks of the same size. The size of each Region block depends on the actual size of the heap space, and the overall control is between 1MB and 32MB, and is 2 The N power of , namely 1MB, 2MB, 4MB, 8MB, 16MB, 32MB. able to pass
XX:G1HeapRegionSize setting. All Regions are the same size and will not be changed during the JVM lifetime.
Although the concepts of the new generation and the old generation are still retained, the new generation and the old generation are no longer physically isolated. They are a collection of a part of Regions (does not need to be continuous). Logical continuity is achieved through the dynamic allocation of Regions.

A Region may belong to Eden, Survivor or Old/Tenured memory area. But a Region can only belong to one role. E in the figure indicates that the Region belongs to the Eden memory area, S indicates that it belongs to the Survivor memory area, and O indicates that it belongs to the Old memory area. Blank spaces in the figure represent unused memory space.
The G1 garbage collector also adds a new memory area called the Humongous memory area, such as the H block in the figure. It is mainly used to store large objects. If there are more than 0.5 Regions, put them in H. (G1 thinks that as long as the size of the object exceeds half of the capacity of a Region, it can be judged as a large object)

Reason for setting H

For large objects in the heap, they will be allocated directly to the old generation by default, but if it is a short-lived large object, it will have a negative impact on the garbage collector. In order to solve this problem, G1 divides a Humongous area, which is used to store large objects. If one H area cannot hold a large object, then G1 will look for a continuous H area to store it . In order to find continuous H areas, sometimes Full GC has to be started. Most of the behavior of G1 treats the H area as part of the old generation.

G1 garbage collection process

The garbage collection process of G1 GC mainly includes the following three links:

Young GC (Young GC)
Old generation concurrent marking process (Concurrent Marking)
Mixed recovery (Mixed GC)
(Single-threaded, exclusive, high-intensity Full GC still exists if needed. It provides a failure protection mechanism for GC evaluation failures, namely strong collection.)

Clockwise, Young GC --> Young GC+Concurrent Marking --> Mixed GC sequence for garbage collection

recycling process

The application allocates memory, and starts the young generation collection process when the Eden area of the young generation is exhausted; the young generation collection phase of G1 is a parallel exclusive collector. During the young generation collection period, G1 GC suspends all application threads and starts multi-threading to perform young generation collection. Then move the surviving objects from the young generation interval to the Survivor interval or the old interval, or both intervals may be involved.
When the heap memory usage reaches a certain value (45% by default), the concurrent marking process of the old generation starts.
Once the marking is complete, the mixed recovery process begins immediately. For a mixed collection period, the G1 GC moves surviving objects from the old generation to free regions, which then become part of the old generation. Unlike the young generation, the old generation G1 collector is different from other GCs. The G1 old generation collector does not need to recycle the entire old generation. It only needs to scan/recycle a small part of the old generation Region at a time . At the same time, the old generation Region is recycled together with the young generation.
For example: a web server, the Java process has a maximum heap memory of 4G, responds to 1500 requests per minute, and allocates about 2G of memory every 45 seconds. G1 will recycle the young generation every 45 seconds, and the usage rate of the entire heap will reach 45% every 31 hours. It will start the concurrent marking process of the old generation, and start four to five mixed collections after the marking is completed.

Remembered Set

The problem that an object is referenced by different regions
A Region cannot be isolated. Objects in a Region may be referenced by objects in any other Region. When judging the survival of an object, does it need to scan the entire Java heap to ensure accuracy?
In other generational collectors, this problem also exists (and G1 is more prominent, because G1 is mainly for large heaps)
Recycling the new generation also has to scan the old generation at the same time? This will reduce the efficiency of Minor GC

Solution:

Regardless of G1 or other generational collectors, JVM uses Remembered Set to avoid full heap scanning;
Each Region has a corresponding Remembered Set
Every time the Reference type data is written, a Write Barrier will be generated to temporarily interrupt the operation;
Then check whether the object pointed to by the reference to be written is in a different Region from the Reference type data (other collectors: check whether the old generation object refers to the new generation object);
If they are different, record the relevant reference information into the Remembered Set corresponding to the Region where the reference points to the object through CardTable;
When performing garbage collection, add the Remembered Set to the enumeration range of the GC root node; it can ensure that no global scanning is performed and there will be no omissions.

G1 recycling process 1: young generation GC

When the JVM starts, G1 prepares the Eden area first, and the program continuously creates objects to the Eden area during the running process. When the Eden space is exhausted, G1 will start a young generation garbage collection process.
Young generation recycling only recycles the Eden area and the Survivor area
During YGC, first G1 stops the execution of the application program (Stop-The-World), and G1 creates a collection set (Collection Set). The collection set refers to the collection of memory segments that need to be reclaimed. The collection set of the young generation collection process contains young Generation of all memory segments in the Eden area and the Survivor area.

Then start the recycling process as follows:

The first stage, scanning the root

The root refers to GC Roots, and the root reference together with the external reference recorded by RSet serves as the entry point for scanning surviving objects.

The second stage, update RSet

Process the cards in the dirty card queue and update Rset. After this phase is complete. RSet can accurately reflect the reference of the old generation to the memory segment object where it is located.

For the application's reference assignment statement oldObject.field (this is the old generation) = object (this is the new generation), the JVM will perform special operations before and after to enqueue an object reference information in the dirty card queue card. When the young generation recycles, G1 will process all the cards in the Dirty Card Queue to update the RSet to ensure that the RSet accurately reflects the reference relationship in real time.

Then why not update the RSet directly at the reference assignment statement? This is for performance needs. The processing of RSet requires thread synchronization, which will cause a lot of overhead, and the performance of using queues will be much better.

The third stage, processing RSet

Identify the objects in Eden that are pointed to by the old generation objects. These objects in Eden that are pointed to are considered to be live objects.

In the fourth stage, the object is copied.

At this stage, the object tree is traversed, and the surviving objects in the memory segment of the Eden area are copied to the empty memory segment in the Survivor area, and the surviving objects in the memory segment of the Survivor area
If the age does not reach the threshold, the age will be increased by 1, and if the threshold is reached, it will be copied to the empty memory segment in the Old area.
If the Survivor space is not enough, part of the data in the Eden space will be directly promoted to the old generation space.

The fifth stage, processing references

Handles Soft, Weak, Phantom, Final, JNI Weak, etc. references. In the end, the data in the Eden space is empty, the GC stops working, and the objects in the target memory are stored continuously without fragmentation, so the copy process can achieve the effect of memory organization and reduce fragmentation.

G1 recycling process 2: concurrent marking process

Initial marking phase : mark objects that are directly reachable from the root node. This phase is STW and triggers a young generation GC. It is precisely because this stage is STW, so we only scan the objects reachable from the root node to save time.
Root Region Scanning (Root Region Scanning): G1 GC scans the objects in the old age region that are directly reachable in the Survivor region, and marks the referenced objects. This process must be completed before Young GC, because Young GC will use the replication algorithm to GC the Survivor area.
Concurrent Marking :
1. Concurrent marking (and application execution) is performed on the entire heap, which may be interrupted by Young GC.
2. During the concurrent marking phase, if all objects in the area object are found to be garbage, the area will be recycled immediately.
3. At the same time, during the concurrent marking process, the object liveness (proportion of surviving objects in the region) is calculated for each region.
Remark (Remark) : As the application continues, it is necessary to revise the last mark result. It's from STW. The original snapshot algorithm faster than CMS is adopted in G1: Snapshot-At-The-Beginning (SATB).
Exclusive cleanup (cleanup, STW) : calculate the proportion of surviving objects and GC recovery in each area, and sort them to identify areas that can be mixed and recovered. Pave the way for the next stage. It's from STW. This phase does not actually do garbage collection
Concurrent cleanup phase : completely free regions are identified and cleaned up.

G1 recycling process three: mixed recycling process

When more and more objects are promoted to the Old Region, in order to avoid the exhaustion of heap memory, the virtual machine triggers a mixed garbage collector, that is, Mixed GC. This algorithm is not an Old GC, except for reclaiming the entire Young Region , and part of the Old Region will be recovered. It should be noted here: it is part of the old age, not all the old age. Which Old Regions can be selected for collection, so that the time-consuming time of garbage collection can be controlled. Also note that Mixed GC is not Full GC.

Mixed Recycling Details

After the concurrent marking ends, the memory segments that are 100% garbage in the old generation are reclaimed, and the memory segments that are partially garbage are calculated. By default, these memory segments in the old generation will be reclaimed in 8 times (can be set by -XX:G1MixedGCCountTarget). [It means that a Region will be divided into 8 memory segments]
The collection set of mixed recovery includes one-eighth of the memory segments of the old age, the memory segments of the Eden area, and the memory segments of the Survivor area. The mixed recycling algorithm is exactly the same as the young generation recycling algorithm, except that the old generation memory segments are added to the recycling collection. For details, please refer to the Young Generation Recycling Process above.
Since the memory segments in the old generation are recycled 8 times by default, G1 will give priority to recycling the memory segments with more garbage. The higher the ratio of garbage to the memory segment, the more it will be recycled first. And there is a threshold that will determine whether the memory segment is reclaimed. XX: G1MixedGCLiveThresholdPercent, the default is 65%, which means that the garbage will only be recycled when the proportion of the memory segment reaches 65%. If the proportion of garbage is too low, it means that the proportion of surviving objects is high, and it will take more time to copy.
Mixed recovery does not have to be performed 8 times. There is a threshold -XX:G1HeapWastePercent, the default value is 10%, which means that 10% of the space in the entire heap memory is allowed to be wasted, which means that if it is found that the proportion of recyclable garbage in the heap memory is less than 10%, it will no longer Perform mixed recycling. Because GC takes a lot of time but reclaims very little memory.

G1 recovery optional process four: Full GC

The original intention of G1 is to avoid the occurrence of Full GC. However, if the above method does not work properly, G1 will stop the execution of the application (Stop-The-World), and use a single- threaded memory recovery algorithm for garbage collection. The performance will be very poor, and the application pause time will be very long.
To avoid the occurrence of Full GC, once Full GC occurs, JVM parameters need to be adjusted. When will Ful1GC happen? For example, if the heap memory is too small, when G1 has no empty memory segments available when copying surviving objects, it will fall back to Full GC. This situation can be solved by increasing the memory.

There may be two reasons for G1 Full GC:

During Evacuation, there is not enough to-space to store promoted objects;
Space was exhausted before concurrent processing was complete.

G1 Supplement

From the official information disclosed by Oracle, we can know that the recovery stage (Evacuation) was actually designed to be executed concurrently with the user program, but this is more complicated to do. Considering that G1 only returns a part of the Region, the pause time is the user It is controllable, so it is not urgent to implement it, but chooses to put this feature in the low-latency garbage collector (ie ZGC) that appears after G1. **In addition, considering that G1 is not only for low latency, pausing user threads can greatly improve the efficiency of garbage collection. In order to ensure throughput, we chose to completely suspend the implementation of user threads.

Optimization suggestions for the G1 collector

young generation size
- Avoid explicitly setting the young generation size with related options such as -Xmn or -XX:NewRatio , as a fixed young generation size overrides predictable pause time goals. We let G1 adjust itself
Don’t be too strict about your pause time goals
- The throughput target for G1 GC is 90% application time and 10% garbage collection time
- When evaluating the throughput of G1 GC, the pause time goal should not be too strict. Goals that are too strict mean that you are willing to incur more garbage collection overhead, which directly impacts throughput.

8- Garbage Collector Summary

As of JDK1.8, there are 7 different garbage collectors. Each type of garbage collector has different characteristics. When using it, you need to choose a different garbage collector according to the specific situation.

All connections in JDK7 can be used

The red line in JDK8 is obsolete, but it can be used

The red line in JDK9 is completely unusable

JDK14 moved out of CMS

JDK14k green line mark is invalid

How to choose a garbage collector

The configuration of the Java garbage collector is a very important choice for JVM optimization. Choosing the right garbage collector can greatly improve the performance of the JVM.

How to choose a garbage collector?

Prioritize adjusting the size of the heap to allow the JVM to complete it adaptively.
If the memory is less than 100M, use the serial collector
If it is a single-core, stand-alone program, and there is no pause time requirement, the serial collector
If it is multi-CPU, high throughput is required, and the pause time is allowed to exceed 1 second, choose parallel or JVM to choose
If it is multi-CPU, pursues low pause time, and needs fast response (for example, the delay cannot exceed 1 second, such as Internet applications), use a concurrent collector
The official recommendation is G1, which has high performance. Now Internet projects basically use G1 .

Finally, one point needs to be clarified:

There is no best collector, let alone a universal collection algorithm
Tuning is always for specific scenarios and specific needs, there is no one-and-done collector

interview

For garbage collection, the interviewer can step by step from various angles of theory and practice, and it does not necessarily require the interviewer to understand everything. But if you understand the principle, it will definitely become a bonus item in the interview.
The more general and basic parts here are as follows:
- What are the algorithms for garbage collection? How to judge whether an object can be recycled?
- The basic flow of garbage collector work.
In addition, you need to pay more attention to the various commonly used parameters in this chapter of the garbage collector

9-GC log analysis

Common parameter configuration

GC log parameter settings

By reading the GC log, we can understand the memory allocation and recovery strategy of the Java virtual machine.

List of parameters for memory allocation and garbage collection

-XX:+PrintGC : Output GC log. Similar to: -verbose:gc
-XX:+PrintGCDetails : output detailed GC logs
-XX:+PrintGCTimestamps : Output GC timestamps (in the form of base time)
-XX:+PrintGCDatestamps : Output GC timestamps (in date form, such as 2013-05-04T21: 53: 59.234 +0800)
-XX:+PrintHeapAtGC : Print out heap information before and after GC
-Xloggc:…/logs/gc.log : the output path of the log file

-verbose:gc

Open GC log:

-verbose:gc

This will only show the total GC heap changes, as follows:

Parameter analysis:

-XX:+PrintGCDetails

1. JVM parameters

-XX:+PrintGCDetails

2. Enter the information as follows

3. Parameter Analysis

-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps

1. JVM parameters

-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps

2. The output information is as follows

3. Description: The log has the date and time

GC Log Supplement

"[GC" and "[Full GC" indicate the pause type of this garbage collection. If there is "Full", it means that GC has "Stop The World"
The name of the new generation using the Serial collector is Default New Generation, so the display is "[DefNew"
Using the ParNew collector, the name of the new generation will become "[ParNew", which means "Parallel New Generation"
The name of the young generation using the Parallel scavenge collector is "[PSYoungGen"
The collection of the old generation is the same as that of the new generation, and the name is also determined by the collector
If the G1 collector is used, it will be displayed as "garbage-first heap"
Allocation Failure indicates that the reason for the GC this time is that there is not enough space in the young generation to store new data.
[ PSYoungGen: 5986K->696K(8704K) ] 5986K->704K (9216K)
- In square brackets: the size of the young generation before GC recovery, the size after recovery, (total size of the young generation)
- Outside the brackets: the size of the young generation and the old generation before GC recovery, the size after recovery, (the total size of the young generation and the old generation)
user represents the time-consuming recovery in user mode, the time-consuming recovery in sys kernel mode, and the actual time-consuming in real. Due to multi-core thread switching, the total time may exceed the real time

Young GC

/**
 * -Xms20M -Xmx20m -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 * -Xmn10M 指明新生代大小10m
 */
public class GCLogTest1 {
    
    

  public static final int _1MB = 1024 * 1024;


  public static void main(String[] args) {
    
    
    testAllocation();
  }
  
  public static void testAllocation() {
    
    
    byte[] allocation1,allocation2,allocation3,allocation4;
    allocation1 = new byte[2 * _1MB];
    allocation2 = new byte[2 * _1MB];
    allocation3 = new byte[2 * _1MB];
    allocation4 = new byte[4 * _1MB];
  }
}

Common log analysis tools

save log file

JVM parameters : -XLoggc:./logs/gc.log, ./ means the current directory, the current directory where the program runs in IDEA is the root directory of the project, not the root directory of the module

You can use some tools to analyze these GC logs. The commonly used log analysis tools are:

GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等

Recommended: GCeasy

Online analysis website: gceasy.io

10 - New Developments in Garbage Collectors

The evolution of the garbage collector

GC is still in rapid development. The current default option, G1 GC, is constantly being improved. Many of the shortcomings we originally thought, such as serial Full GC and low efficiency of Card Table scanning, have been greatly improved. For example, After JDK10, Fu11GC is already running in parallel. In many scenarios, its performance is slightly better than ParallelGC's parallel Ful1GC implementation.
Even though SerialGC is relatively old, its simple design and implementation are not necessarily obsolete. Its own overhead, whether it is the overhead of GC-related data structures or the overhead of threads, is very small, so with the development of cloud computing Rise, in new application scenarios such as serverless, Serial Gc has found a new stage.
Unfortunately, CMSGC has been marked as obsolete in JDK9 and removed in JDK14 because of the theoretical defects of its algorithm and other reasons. Although there is still a very large user group
The G1 collector has been the default collector for several years now.
We also saw the introduction of two new collectors: ZGC (appeared in JDK11) and Shenandoah (Open JDK12), which feature: low pause time

New features of JDK11

Shenandoah GC

Shenandoash GC for Open JDK12: GC with low pause times (experimental)

Shenandoah is undoubtedly the loneliest of many GCs. It is the first Hotspot garbage collector not led by the Oracle team. Inevitably subject to official exclusion. For example, Oracle, which claims that there is no difference between openJDK and OracleJDK, still refuses to support Shenandoah in OracleJDK12.
The Shenandoah garbage collector was originally implemented by Pauseless GC, a garbage collector research project conducted by RedHat, aiming at low-pause requirements for memory recovery on the JVM. Contributed to OpenJDK in 2014.
The Red Hat R&D Shenandoah team claims that the pause time of the Shenandoah garbage collector has nothing to do with the heap size, which means that no matter whether the heap is set to 200MB or 200GB, 99.9% of the goals can limit the pause time of garbage collection to within ten milliseconds. However, actual usage performance will depend on the actual working heap size and workload.

This is the paper data published by RedHat in 2016. The test content is to use ES to index 200GB of Wikipedia data. From the results:

The pause time has indeed made a qualitative leap compared to several other collectors, but it has not achieved the goal of controlling the maximum pause time within ten milliseconds.
There was a noticeable drop in throughput, and the total run time was the longest of all test collectors.

This is the paper data published by RedHat in 2016. The test content is to use ES to index 200GB of Wikipedia data. From the results:

The pause time has indeed made a qualitative leap compared to several other collectors, but it has not achieved the goal of controlling the maximum pause time within ten milliseconds.
There was a noticeable drop in throughput, and the total run time was the longest of all test collectors.

Shocking, Revolutionary ZGC

Official documentation: https://docs.oracle.com/en/java/javase/12/gctuning/

The goal of ZGC is highly similar to that of Shenandoah. Under the premise of having as little impact on throughput as possible, it can achieve low latency that can limit the pause time of garbage collection to less than ten milliseconds under any heap memory size.
The book "In-depth Understanding of the Java Virtual Machine" defines ZGC as follows: The ZGC collector is based on the Region memory layout, (temporarily) without generation, and uses technologies such as read barriers, dyed pointers, and memory multiple mapping. Concurrent mark-compression algorithm, a garbage collector with low latency as the primary goal.
The working process of ZGC can be divided into 4 stages: concurrent marking - concurrent preparatory reallocation - concurrent reallocation - concurrent remapping, etc.
ZGC is executed concurrently almost everywhere, except for initial marking which is STW. So the pause time is almost spent on the initial marking, the actual time of this part is very little.

throughput

max-JOPS: data with low latency as the primary premise

critical-JOPS: Does not consider data under low latency

low latency

[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-sBSK78bC-1663494341093) (C:\Users\86156\AppData\Roaming\Typora\typora-user-images\ image-20220918151730788.png)]

In ZGC's strong pause time test, it mercilessly opened the gap between Parallel and G1 by two orders of magnitude. Regardless of the average pause, 95% pause, 998 pause, 99.98 pause, or the maximum pause time, ZGC can easily control it within 10 milliseconds.

Although ZGC is still in the experimental state and has not completed all the features, the performance is already quite impressive at this time. It is not an exaggeration to describe it as "shocking and revolutionary". It will be the preferred garbage collector for server-side, large-memory, and low-latency applications in the future.

Before JDK14, ZGC was only supported by Linux.
While many users of ZGC use Linux-like environments, people also need ZGC for development deployment and testing on Windows and macOS. Many desktop applications can also benefit from ZGC. Therefore, the ZGC feature was ported to Windows and macOS.
Now ZGC can also be used on mac or Windows, examples are as follows:

-XX:+UnlockExperimentalVMOptions-XX：+UseZGC

AliGC for large heaps

AliGC is based on the G1 algorithm of the Alibaba JVM team and is oriented to large heap (Large Heap) application scenarios. Contrast in the specified scene:

at last: