CMS garbage collector

Want to make APP Same thing as WeChat , Can run small programs smoothly ？ | Experience will send you to Xinjiang 、 Huawei 、 Cherry keyboard ！>>>

CMS Garbage collector collection step by step

• Initial marker (Stop the world)
• Concurrent Tags
• Pre cleaning
• Pre cleaning that can be terminated
• Re label (Stop the world)
• Concurrent elimination
• Concurrent reset

Initial marker

> Mark GcRoots Direct access to the elderly , Old age objects referenced by new generation surviving objects . The whole process is in JDK1.7 Is single threaded in JDK1.8 Is multithreaded ( adopt CMSParallelInitialMarkEnabled Parameter adjustment ). This process can lead to STW.

Concurrent Tags

> from Initial marker Phase marked objects start , Mark other living objects , At this stage, the garbage collection thread and the application thread run simultaneously . Because it's running at the same time , Application threads are still running , It will lead to the promotion of the object , Changes in object references , Special objects are assigned directly to the old age . These affected objects of the old age are Card Will be marked as Dirty, For relabeling phase scanning , The object of the old age Card Marked as Dirty The possible reasons for this are shown in the green line below .

Pre cleaning

> Since the previous phase was executed concurrently, unmarked change objects are only marked as Dirty object , Not yet dealt with , Pre cleaning It's to mark these Dirty object . Here's the picture : In the concurrent tagging phase 3 Number Card Marked as Dirty. This stage is for Re label Stage preparation .

Pre cleaning will 6 No. 1 is a living object

Pre cleaning that can be terminated

> This stage is also a preparation for the re marking stage , Before entering the re labeling phase , It's better to have a Minor GC, Clean up the younger generation , This will clear most of the younger generation's targets ( The vast majority of young people live and die ), Try to shorten Re label Stage pause time ,CMS It also provides CMSScavengeBeforeRemark Parameters , It can be forced to proceed in sequence before entering the relabeling Minor gc.

Re label (remark)

> Pre cleaning and Pre cleaning that can be terminated All for Re label Stage preparation , because Re label Stage will happen (STW), So make sure you have as much pause time as you can , Otherwise, it will affect the user experience of the application . The target of this phase of scanning is : The younger generation +GC Roots+Dirty Old age object , This phase is multithreaded (XX:+CMSParallelRemarkEnabled).

Concurrent elimination

> The user thread is activated , Objects that are not marked are cleared .'

Concurrent reset

> CMS The garbage collector parameter returns to its initial state , Prepare for the next garbage collection .

Use CMS What to pay attention to in garbage collector

Re label The pause time is too long

> 80% Time spent in Re label Stage , If you find that Re label Stage pause time is too long , Try adding -XX:+CMSScavengeBeforeRemark, stay Re label Do it once before Minor GC, The goal is to reduce invalid references to older objects , Reduce Re label The cost of .

Memory fragmentation problem

> CMS It's based on markers - Clearing algorithm's ,CMS Only garbage objects will be deleted , Does not compress memory space , Will cause memory fragmentation . We need to use -XX:CMSFullGCsBeforeCompaction=n Parameters to adjust , It means last time CMS After concurrent execution , How many more times to execute Full GC To do memory compression .

concurrent mode failure

> stay CMS GC In the process, because the app is also running , At that time, the light generation was full of , Yes Minor GC Now , You need to put the surviving objects into the older generation , At this time, there is not enough space for the elderly , At this time CMS There's no chance to recycle the older generation . You can set the following two parameters

• -XX:CMSInitiatingOccupancyFraction=75

> CMS The utilization rate of memory reaches 75% Will start GC, The default is 92%, Too high will lead to promotion failed

• -XX:+UseCMSInitiatingOccupancyOnly

> If not set UseCMSInitiatingOccupancyOnly, Only set CMSInitiatingOccupancyFraction that JVM Only for the first time , It will be adjusted automatically later .

> Why set the above two parameters , In the garbage collection stage , The user thread is still running , So you have to leave enough space for user threads to run .CMS The first five stages are all marked with living objects , except ” Initial marker ” and ” Re label ” Stage meeting stop the word , The other three phases are run with the user thread , That's what happens gc Thread is marking live objects , User threads also promote new objects to the old age , The cleaning up has not started yet ,old gen There's no room for more objects , This will lead to concurrent mode failure, And then you'll use a serial collector to recycle old-fashioned garbage , It took a long time to cause a pause . CMSInitiatingOccupancyFraction Set a reasonable value for the parameter , The settings are big , Will increase concurrent mode failure Frequency of occurrence , The settings are small , It will increase again CMS frequency , So choose a reasonable value according to the running situation of the application . If it is found that these two parameters are set too large, it will lead to full gc, Small settings will cause frequent CMS GC, It means that the space in your old age is too small , It's time to increase the size of space for the elderly .

promotion failed

> It's going on Minor GC when ,Survivor space can't let go , The object can only be put into the old generation , At this time, the old generation can't let go , Most of the time, there are too many memory fragments in the old days , As a result, there is no continuous space for objects .

Premature promotion and promotion failure

> happen Minor GC when , If the object is too large (Survivor Space It can't be stored ) It's basically going to go back to the old days , This phenomenon is called premature promotion , This will result in the older generation being augmented by short-term and medium-term objects , Can cause serious performance problems . If the old generation is full , Will trigger Full GC, This will result in traversing the entire heap , Promotion failure .

Solution

• If a large object promotion failure is caused by memory fragmentation ,cms Need to do space consolidation and compression ;
• If it's due to too fast ascension , explain Survivor Insufficient free space , Then try to turn it up Survivor;
• If it's due to the lack of space for the elderly , Try to CMS The trigger threshold is lowered .

CMS summary

• CMS Only the older generation , Response speed first .
• Re labeling will STW, Long pause time , So do one before this Minor GC, Will reduce a lot of invalid references to older objects .
• Memory fragmentation problem caused by Full GC, Please use -XX:CMSFullGCsBeforeCompaction=n, Organize the memory regularly to reduce memory fragmentation .
• JDK1.7,JDK1.8 Set up CMS Garbage collector XX:+UseConcMarkSweepGC

Several important CMS Parameters

• -XX:CMSFullGCsBeforeCompaction=n Full GC n After the memory compression
• -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly Memory footprint 70% Will trigger CMS GC
• -XX:+CMSScavengeBeforeRemark CMS GC Do it once before Minor GC