Garbage Collector and Memory Allocation (Chapter 5)

"Practical Java Virtual Machine: JVM Fault Diagnosis and Performance Optimization (2nd Edition)"
Java Platform, Standard Edition Hotspot Virtual Machine Garbage Collection Tuning Guide

Although there seem to be a large number of garbage collectors, in fact, the overall logic is a product that has evolved due to the upgrade of the hardware environment. The production of different garbage collectors can be divided into several stages.

• Single-threaded collection era (Serial and Serial Old)
• Multi-threaded collection era (Parallel Scanvenge and Parallel Old)
• Concurrent collection era (ParNew and CMS)
• Intelligent concurrent collection era (G1)

Garbage collection is divided into generational collection and partition collection:

• Generational recycling: Serial, Serial Old, Parallel Scavenge, Parallel Old, ParNew, CMS
• Partition recycling: G1, ZGC, Shenandoah

Chapter 5 Garbage Collector and Memory Allocation

5.1. Serial collector (one thing at a time)

1. Use a single thread for garbage collection. There is only one working thread for each collection; it is a mature and extremely efficient collector that has been tested in a long-term production environment; 2. Features:
focus and exclusivity
3. Applicable scenarios: Computers with weak parallel capabilities;
4. Usable scenarios: new generation and old generation;
5. Classification:
According to the different heap spaces, it is divided into new generation serial collector and old generation serial collector.

5.1.1. New generation serial collector - Serial

1. The oldest and one of the most basic garbage collectors in JDK;
2. Features:

• Use a single thread for garbage collection;
• Exclusive garbage collection;

3. Adopt a copy algorithm; the implementation is relatively simple, the logic processing is particularly efficient, and there is no thread switching overhead;
4. When the hardware platform such as a single CPU processor is not particularly superior, the performance can exceed the parallel collector and concurrent collector;
5. Use -XX:+UseSerialGCparameters to specify the use of the new generation serial collector or the old generation serial collector; when the JVM is running in Client mode, it is the default garbage collector; 6. Note: Although the
serial garbage collector is old, it has been around for a long time. Tested. In most cases, its performance is quite good;

When the serial collector performs garbage collection, the threads in the Java application need to pause and wait for the garbage collection to complete. As shown in Figure 5.1, when the serial collector is running, all threads in the application stop working and wait. This phenomenon is called "Stop-The-World". It will cause a very bad user experience, which is often unacceptable in application scenarios with high real-time requirements.

5.1.2. Old generation serial collector - Serial Old

1. Use mark compression algorithm;
2. Like the Serial collector, it is a serial and exclusive garbage collector;

3. To enable the serial collector in the old generation, you can try to use the following parameters:
-XX:+UseSerialGC: Use the serial collector in both the new generation and the old generation;
-XX:+UseParNewGC: Use the ParNew collector in the new generation, and use the serial collector in the old generation; (JDK9, JDK10 has been deleted because ParNew needs to work with CMS, and CMS has been replaced by G1 and no longer supports this parameter)
-XX:+UseParallelGC: the new generation uses the ParallelGC collector, and the old generation uses the serial collector;

Since old generation garbage collection usually takes longer than young generation collection, in applications with large heap space, once the old generation serial collector starts, the application is likely to be paused for a long time.
Even so, as a veteran garbage collector, the old generation serial collector can be used in conjunction with a variety of new generation collectors, and it can also be used as a backup collector for the CMS collector.

5.2. Parallel collector (more people, more power)

1. The parallel collector improves on the serial collector and uses multiple threads to perform garbage collection at the same time;
2. For computers with strong parallel capabilities, it can effectively shorten the actual time required for garbage collection;

5.2.1. New generation collector - ParNew

1. Works in the new generation;
2. It simply multi-threads the serial collector, and its recycling strategy, algorithm and parameters are the same as those of the new generation serial collector;
3. Exclusive collector, during the collection process, Applications will all be suspended;

The parallel collector uses multiple threads for garbage collection. Therefore, on a CPU with strong concurrency capabilities, the pause time it generates is shorter than that of the serial collector. On the other hand, in systems with weak CPU or concurrency capabilities, the parallel collector The effect will not be better than the serial collector. Due to the pressure of multi-threading, its actual performance is likely to be worse than the serial collector;

4. You can use the parameters to turn on the ParNew recycler:
-XX:+UseParNewGC: The new generation uses the ParNew recycler, and the old generation uses the serial recycler; (JDK9 and JDK10 have been deleted because ParNew needs to work with CMS, and CMS has been replaced by G1 and is no longer This parameter is supported)
-XX:+UseConcMarkSweepGC: The new generation uses the ParNew collector, and the old generation uses CMS; (JDK9 and JDK10 are not recommended, and it is recommended to use the default G1 garbage collector)
5. You can use -XX:ParallelGCThreadsparameters to specify the number of threads during work. Generally, it is best to match the number of CPUs to avoid excessive thread numbers, which may affect garbage collection performance. By default, when the number of CPUs is less than 8, the value of ParallelGCThreads is equal to the number of CPUs. When the number of CPUs is greater than 8, the value of ParallelGCThreads is equal to 3+((5*CPU_Count)/8);

5.2.2. New generation collector - ParallelGC

1. Adopts a copy algorithm;
2. Like the ParNew collector, it is multi-threaded and exclusive;
3. Features: Pays great attention to the throughput of the system;
4. The new generation collector ParallelGC collector can be enabled using the following parameters:
-XX:+UseParallelGC: Used by the new generation ParallelGC collector, the old generation uses the serial collector;
-XX:+UseParallelOldGC: The new generation uses the ParallelGC collector, the old generation uses the ParallelOldGC collector;
5. The ParallelGC collector provides two important parameters for controlling the throughput of the system:
-XX:MaxGCPauseMillis: Set the maximum Garbage collection pause time, the value is an integer > 0; when Parallel is working, it will adjust the Java heap size or other parameters to control the pause time within MaxGCPauseMillis as much as possible. A small value will cause garbage collection to become very frequent, thereby increasing the total garbage collection time and reducing throughput;
-XX:GCTimeRatio: Set the throughput size, the value is an integer between 0 and 100; assuming that the value of GCTimeRatio is n, the system will spend no more than 1/(1+n) of the time is used for garbage collection; by default, the value is 99, that is, no more than 1/(1+99) = 1% of the time is used for garbage collection;

Another difference between ParallelGC and ParNew is that it also supports an adaptive GC adjustment strategy; using it -XX:+UseAdaptiveSizePolicycan turn on the adaptive GC strategy; in this mode, the size of the new generation, the ratio of the eden area and the survivor area, promotion Parameters such as object age in the old generation are automatically adjusted to achieve a balance between heap size, throughput and pause time. In situations where manual tuning is difficult, you can directly use this adaptive method, specifying only the JVM's maximum heap, target throughput (GCTimeRatio) and pause time (MaxGCPauseMillis), and let the JVM complete the tuning work by itself.

6. The -XX:MaxGCPauseMillisparameters -XX:GCTimeRatioare contradictory to each other. If you reduce the maximum pause time of a collection, it will also reduce the system throughput. Increasing the system throughput may also increase the maximum pause time of a garbage collection;

5.2.3. Old generation collector - ParallelOldGC

1. Multi-thread concurrency;
2. Like the new generation collector ParallelGC, it is also a collector that focuses on throughput;
3. The old generation collector is used in conjunction with ParallelGC and the new generation collector;
4. Use mark compression method; in JDK1. It can only be used in 6;
5. Parameters:
-XX:+UseParallelOldGC: Use the ParallelGC collector in the new generation, and use the ParallelOldGC collector in the old generation; (This is a pair of garbage collectors that pay great attention to throughput, and can be considered in systems that are sensitive to throughput. Use)
-XX:ParallelGCThreads: can be used to set the number of threads during garbage collection;

5.3. CMS recycler (multi-tasking without missing a beat) (JDK8 and previous versions)

1. Pay attention to the system pause time.
2.CMS is the abbreviation of Concurrent Mark Sweep, which means concurrent mark clearing;
3. Adopt mark clearing method;
4. Multi-threaded parallel recycling;

5.3.1. Main working steps of CMS

1. The main steps when CMS works are: initial marking, concurrent marking, pre-cleaning, re-marking, concurrent clearing and concurrent reset; 2.
Initial marking and re-marking exclusive system resources; pre-cleaning, concurrent marking, concurrent clearing And concurrency reset can be performed with user threads.
3. On the whole, CMS is not exclusive and can perform garbage collection while the application is running.

According to the mark-and-sweep method, initial marking, concurrent marking, and re-marking are all used to mark objects that need to be recycled. Concurrent cleanup is to formally recycle garbage objects after marking is completed. Concurrent reset refers to reinitializing the CMS data structure and data after garbage collection is completed to prepare for the next garbage collection. Concurrency marking, concurrency cleanup, and concurrency reset can all be performed with application threads.
During the entire CMS recycling process, by default, there will be a pre-cleaning operation after concurrent marking (the switch can also be turned off -XX:-CMSPrecleaningEnabledto not perform pre-cleaning). Pre-cleaning is concurrent. In addition to preparing and checking for formal cleaning, it also tries to control the time of a pause. Since remarking is exclusive to the CPU, if a remarking is triggered immediately after the young generation GC occurs, the pause time may be very long. In order to avoid this situation, preprocessing will deliberately wait for a new generation GC to occur, then predict the time when the next new generation GC may occur based on historical performance data, and re-mark the time between the current time and the predicted time. This can try to avoid the coincidence of new generation GC and re-marking, and reduce the time of a pause as much as possible.

5.3.2. CMS main parameters

1.: -XX:+UseConcMarkSweepGCEnable CMS recycler;
2 -XX:ParallelGCThreads.: Set the number of threads used in parallel GC. If the new generation uses ParNew, ParallelGCThreads is also the number of threads of the new generation GC; the default number of concurrent threads started is (ParallelGCThreads+3)/4 ; This means that when there are 4 ParallelGCThreads, there is only 1 concurrent thread, and when there are two concurrent threads, there are 5-8 ParallelGCThreads threads;
3. -XX:ConcGCThreads, -XX:ParallelCMSThreads: Set the number of concurrent threads;
4. Note:
(1) Concurrency: Refers to the alternate execution of the collector and application threads;
(2) Parallel: refers to the application stopping and multiple threads executing GC at the same time; (the parallel collector is not concurrent)

Since the CMS collector is not an exclusive collector, the application is still working continuously during the CMS recycling process. During the working process of the application, garbage will continue to be generated. These newly generated garbage cannot be removed during the current CMS recycling process. At the same time, because the application is not interrupted, you should also ensure that the application has enough memory available during the CMS recycling process. Therefore, the CMS collector will not wait for the heap memory to be saturated before performing garbage collection. Instead, it will start recycling when the heap memory usage reaches a certain threshold to ensure that the application still has enough space to support the CMS work process. The application runs.

5.: -XX:CMSInitiatingOccupancyFractionSpecify the recycling threshold, the default is 68, that is, when the space usage of the old generation reaches 68%, a CMS recycling will be performed;

If the application's memory usage increases rapidly and insufficient memory occurs during the execution of CMS, CMS recycling will fail, and the virtual machine will start the old generation serial collector for garbage collection. At this point, the application will be completely interrupted until garbage collection is completed, at which time the application may be paused for a long time.

Depending on the characteristics of the application, parameters can be -XX:CMSInitiatingOccupancyFractiontuned. 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, which can significantly improve application performance. On the other hand, if the application memory usage is growing rapidly, this threshold should be lowered to avoid triggering the old generation serial collector frequently.

6.CMS is based on the mark and clear method, which will generate a large number of memory fragments, and the discrete available space cannot be allocated to larger objects. As shown in Figure 5.5 below, in this case, even if the heap memory still has a large remaining space, it may be forced to perform a garbage collection in exchange for a piece of available contiguous memory. This phenomenon is quite detrimental to system performance. In order to solve this problem, the CMS collector provides several parameters for memory compression and defragmentation: : allows CMS to
-XX:+UseCMSCompactAtFullCollectionperform a memory defragmentation after the garbage collection is completed. Collation is not performed concurrently;
-XX:CMSFullGCsBeforeCompaction: can be used to set how many times CMS recycling is performed before memory compression is performed;

5.3.3. CMS log analysis

This shows that the CMS recycler failed to recycle concurrently. This is most likely caused by insufficient space in the old generation while the application is running. If there are very frequent concurrent mode failures during the CMS work process, you should consider making adjustments and reserve a larger old generation space as much as possible. Or you can set a smaller -XX:CMSInitiatingOccupancyFraction parameter to lower the CMS trigger threshold so that the CMS still has a large old generation free space for applications to use during execution.

5.3.4. Recycling of Class

When using the CMS recycler, if you need to recycle the Perm area, then by default, you need to trigger a Full GC, as shown below:

-XX:+CMSClassUnloadingEnabled: Use the CMS recycler to recycle the Perm area. After using this parameter, if conditions permit, the system will use the CMS mechanism to recycle the Class data in the Perm area. The log is as follows:

5.4. G1 collector (I will decide in the future) (default collector for JDK9 and later versions)

1. The G1 collector (Garbage-First) is a brand-new garbage collector officially used in JDK1.7 to replace the CMS collector.
2. G1 has a unique garbage collection strategy, which is completely different from previous collectors;
3. It is a generational garbage collector, which distinguishes between the young generation and the old generation, and still has the eden area and the survivor area;
4. Uses a partitioning algorithm; It does not require the entire eden area, young generation or old generation to be continuous;
5. Features:
(1) Parallelism : During recycling, multiple GC threads work at the same time; (Effective use of multi-core computing power)
(2) Concurrency : Has The ability to execute alternately with the application, part of the work is available and the application is executed at the same time, generally speaking, the application will not be completely blocked during the entire recycling period; (3) Generational
GC : taking into account both the young generation and the old generation; (Other recycling The server either works in the young generation or in the old generation);
(4) Space defragmentation : During the recycling process, appropriate object movements will be carried out. Each recycling will effectively copy the objects and reduce the fragmented space; unlike CMS, just Simply mark the cleaning object, and after several GCs, CMS must perform a defragmentation;
(5) Predictability : Due to partition reasons, G1 can only select some areas for memory recycling, reducing the scope of recycling, and global pauses can also get better control;

5.4.1. G1 memory division and main collection process

1.G1 partitions the heap into areas. During each recycling, only a few areas are recycled to control the pause time caused by garbage collection; 2. The recycling process may have 4 stages
. :
(1) New generation GC;
(2) Concurrent mark cycle;
(3) Mixed collection;
(4) Full GC may be performed if necessary;

5.4.2. G1’s new generation GC

1. Main work: Recycle the eden area and survivor area;
2. After recycling: the eden area is emptied; part of the survivor area is recycled, and at least one survivor area exists; the old generation area increases (part of the survivor area or eden area objects are promoted);

After the new generation GC occurs, if the PrintGCDetails option is turned on, you can get a GC log similar to the following:

Compared with the logs of other collectors, the log content of G1 is very rich. Of course, what we are most concerned about is still the GC pause time and recycling situation. As can be seen from the log, the eden area originally occupied 235MB of space. It was emptied after recycling. The survivor area grew from 5MB to 11MB. This is because some objects were copied from the eden area to the survivor area. The entire heap totaled 400 MB. The heap memory Dropped from 239MB before recycling to 10.5MB.

5.4.3. Concurrent marking cycle of G1

1. The concurrency phase is similar to CMS. In order to reduce the pause time, the parts that can be concurrent with the application are extracted separately and executed;
2. The concurrent marking cycle is divided into steps:

• Initial marking : marking objects directly reachable from the root node. This stage will be accompanied by a new generation GC, which will cause a global pause. The reference program thread must stop executing at this stage;
• Root area scan : Scan the old generation area directly reachable by the survivor area and mark these directly reachable objects. This process can be executed concurrently with the application, but cannot be executed at the same time as the new generation GC (because the root area scan depends on the objects in the survivor area, and the new generation GC will modify this area). If you happen to need to perform the new generation GC, you need to wait for the root area. It can only be carried out after the scan is completed. In this case, the time of the new generation GC will be extended;
• Concurrent marking : Similar to CMS, concurrent marking will scan and find live objects in the entire heap and mark them; this is a concurrent process and can be interrupted by a new generation GC;
• Re-marking : Like CMS, re-marking will also cause application pauses; since the application is still running during the concurrent marking process, the marking results may need to be corrected, so the last marking results are supplemented here; in In G1, this process is completed using the STAB (Snapshot-At-The-Beginning) algorithm, that is, G1 will create a snapshot of the surviving object at the beginning of marking. This snapshot helps speed up the re-marking;
• Exclusive cleanup : This stage will cause pauses. It will calculate the surviving objects and GC recycling ratios in each area, sort them, and identify the areas available for mixed recycling; at this stage, it will also update the memory set (Remebered Set); this stage gives the areas that need to be mixed recycled. and are tagged, this information is required during the mixed recycling phase;
• Concurrent cleaning : Concurrent cleaning will not cause pauses; completely free areas will be identified and cleaned;

Figure 5.7 shows what the heap might look like before and after a concurrent mark cycle. Since the concurrent marking cycle includes a new generation GC, the new generation will be sorted out. However, since the application is still running when the concurrent marking cycle is executed, new eden area space will be used after the concurrent marking cycle ends. The biggest difference before and after the concurrent marking cycle is that after this phase, the system adds some areas marked G. These regions are marked because they contain a high proportion of garbage and are expected to be collected in subsequent mixed GCs (note that these regions are not officially collected during the concurrent mark cycle). These areas to be recycled will be recorded by G1 in a set called Collection Sets.

The overall workflow of the concurrent recycling phase is shown in Figure 5.8. It can be seen that in addition to initial marking, re-marking and exclusive cleaning, several other phases can be executed concurrently with the application; during the concurrent marking cycle, G1 will generate the following log

:
(1) Initial mark, which is accompanied by a new generation GC. It can be seen that when the initial mark is initialized, the eden area is emptied and partially copied to the survivor area; (2)

A concurrent root area scan, the concurrent scan process cannot be used by the new generation GC interruption; root area scanning will not cause pauses;

(3) Concurrent marking, concurrent marking can be interrupted by the new generation GC. The following log shows that one concurrent marking was interrupted by three new generation GCs;

(4) Re-marking, will cause a global pause, and its log is as follows:

(5) After re-marking, exclusive cleaning will be performed. Exclusive cleaning will recalculate the surviving objects in each area, and in this way, the effect of GC in each area (i.e., recycling ratio) can be obtained. ). Its log is as follows:

(6) Concurrent cleanup is executed concurrently. It will directly recycle areas that no longer contain surviving objects based on the number of surviving objects in each area calculated during the exclusive cleaning phase. Its log is as follows:

5.4.4. Mixed recycling

During the concurrent mark cycle, although some objects are recycled, overall, the recycling rate is quite low. However, after the concurrent marking cycle, G1 has clearly known which areas contain more garbage objects, and can specifically recycle these areas during the mixed collection phase. Of course, G1 will give priority to recycling areas with a higher garbage ratio, because recycling these areas is also more cost-effective. This is where the name G1 comes from. The full name of G1 garbage collector is Garbage First Garbage Collector, which is literally translated as garbage collector with garbage priority. Garbage First here refers to giving priority to the area with the highest garbage ratio during recycling.

This stage is called mixed recycling because during this stage, both the normal young generation GC and some marked old generation areas are selected for recycling. It processes both the new generation and the old generation, as shown in Figure 5.9. Because of the new generation GC, the eden area must be cleared. In addition, two areas with the highest garbage ratio marked G are cleared. Surviving objects in the cleaned area will be moved to other areas. The advantage of this is that it can reduce space fragmentation.


Mixed GC will be executed multiple times until enough memory space is reclaimed, and then it will trigger a new generation GC. After the new generation GC, the processing of a concurrent marking cycle may occur, and finally the execution of the mixed GC will occur. The entire process might look like Figure 5.10.

5.4.5. Full GC when necessary

1. Similar to CMS, concurrent recycling cannot completely avoid insufficient memory during the recycling process because the application and GC threads work alternately. When encountering this situation, G1 will also transfer to a Full GC;
2. When G1 is concurrently marked, since the old generation is quickly filled, G1 will terminate concurrent marking and transfer to a Full GC;
3. If it is mixed Insufficient space during GC, or during new generation GC, the survivor area and old generation cannot accommodate surviving objects, which will lead to a Full GC;

5.4.6. G1 log

A complete G1 new generation log is as follows:

(1) The first line of the log indicates that a new generation GC occurred 1.619 seconds after the application was started. This occurred during the initial mark and took 0.038 seconds, which means that the application It paused for at least 0.038 seconds;
(2) The second line gives the subsequent parallel time. Indicates the total time spent by all GC threads, here it is 38 milliseconds;
(3) The third and fourth lines give the execution status of each GC thread. This represents a total of 4 GC threads (because the first row has 4 data), and they are all started at 1619.3 seconds. At the same time, the statistical values ​​​​of these startup data are also given, such as average (Avg), minimum (Min), maximum (Max) and difference (Diff). Diff represents the difference between the maximum value and the minimum value;
(4) The fifth and sixth lines give the time consumption of the root scan. During the root scan, the time consumption of each GC thread consumes 0.3, 0.3, 0.2, and 0.2 seconds respectively. The latter line gives these time-consuming statistics;
(5) Lines 789 and 90 give the time required to update the Remembered Set. The memory set is a data structure maintained in G1, referred to as RS. Each G1 region has an RS associated with it. Since G1 recycles by area, for example, when recycling objects in area A, it is likely that objects in area B will not be recycled. In order to recycle objects in area A, area B or even the entire heap must be scanned to determine which objects are in area A. It’s not accessible, and the cost of doing so is obviously high. Therefore, G1 records the objects referenced by other areas in area A in the RS of area A. In this way, when recycling area A, it only needs to regard RS as part of the root set of area A, thereby avoiding the need to do a complete heap scanning. Since the reference relationships between objects may change all the time during the running of the system, in order to track these reference relationships more efficiently, these changes will be recorded in Update Buffers. Processed Buffers here refers to processing the Update Buffers data. The 4 times given here are also the time taken by 4 GC threads, as well as their statistics. It can be seen from this log that updating RS takes 5.7, 5.4, 28, and 5.3 milliseconds respectively, with an average time of 11.1 milliseconds; (
6) Lines 11 and 12 indicate the time to scan RS;
(7) In the formal When recycling, G1 will evacuate the objects in the recycled area, that is, place the surviving objects in other areas, so the objects need to be copied. The Object Copy given in lines 13 and 14 is the time taken for object assignment;
(8) Lines 15, 16, 17, and 18 give the termination information of the GC worker thread. The termination time here is the time the thread spends in the termination phase. Before the GC thread terminates, they will check the work queues of other GC threads to see if there are still object references that have not been processed. If other threads still have unprocessed data, the GC thread that requested the termination will help it complete it as soon as possible. Then try to terminate again. Among them, Termination Attempts shows the number of times each worker thread attempts to terminate;
(9) Lines 19 and 20 show the completion time of the GC worker thread. Here it shows that these threads were terminated 1657 milliseconds after the system was running; (10
) Lines 21 and 22 show the time The survival time of a GC worker thread, in milliseconds;
(11) Lines 23 and 24 show the time spent by the GC thread on other tasks, in milliseconds. You can see that this part of the time is very small;
( 12) Line 25 shows the time to clear the CardTable. RS relies on the CardTable to record which objects are alive;
(13) Shows the time taken for several other tasks, such as the time to select CSet (Collection Sets), Ref Proc (processing) Weak reference, soft reference time), Ref Enq (weak reference, soft reference enqueuing time) and Free CSet (the time to release the area in the recycled CSet, including their RS); (14) Display the more familiar GC

recycling The overall situation here shows that a total of 32MB of the eden area has been cleared, no objects have been released in the survivor area, and no space has been released in the entire heap space. The user CPU took 0.16 seconds, and the actual time took 0.04 seconds;

5.4.7. G1 related parameters

1. -XX:+UseG1GC: Turn on the switch of G1;
2. -XX:MaxGCPauseMillis: Used to specify the maximum dwell time of the target. If any pause exceeds this setting value, G1 will try to adjust the ratio of the new generation to the old generation, adjust the heap size, adjust the promotion age, etc., in an attempt to achieve the preset goal. For performance tuning, if the pause time is shortened, for the new generation, this means that the number of new generation GCs is likely to be increased. For the old generation, in order to obtain shorter pause times, the number of areas collected at one time will also be reduced during mixed GC, which undoubtedly increases the possibility of Full GC; 3.: used to set GC during
parallel -XX:ParallelGCThreadscollection The number of working threads;
4 -XX:InitiatingHeapOccupancyPercent.: You can specify when the entire heap usage reaches the level to trigger the execution of the concurrent mark cycle. The default value is 45, that is, when the occupancy rate of the entire heap reaches 45%, a concurrent mark cycle is executed. Once this value is set, it will never be modified by G1, which means that G1 will not try to change this value to meet the goal of MaxGCPauseMillis. If this value is set to a large value, the concurrent cycle will not start for a long time, and the possibility of causing Full GC will also be greatly increased. On the contrary, an InitiatingHeapOccupanyPercent value that is too small will cause the concurrent mark cycle to be executed very frequently, and a large number of GC threads will Seizes the CPU, resulting in reduced application performance.