jvmgc--Concurrent Collector (CMS) __javase

CMS (Concurrent Mark Sweep) collector

C:concurrent

M: Tag (Marking) object: GC must remember which objects are available to delete unreachable objects

S: Clear (sweeping): Remove unmarked objects and free their memory

CMS is a collector with the shortest pause time, and the CMS does not achieve the highest GC efficiency, but it minimizes the downtime of the service at GC.

Use the mark-purge algorithm (Mark Sweep) to generate memory fragmentation at run time

The virtual machine provides the parameters to open the CMS after the collection is completed and then a memory compression.

-xx:+useconcmarksweepgc

Activate the CMS collector. The default hotspot JVM uses a parallel collector

-xx:+usecmscompactatfullcollection

Sets whether a memory defragmentation process is required after the garbage collector and is valid only when the CMS collector is-xx:+cmsfullgcbeforecompaction
Set up the CMS collector a memory defragmentation process is typically used with the usecmscompactatfullcollection parameter after several times of garbage collection

The whole process of CMS garbage collection is divided into six steps:

1. Initial mark (CMS initial mark) will STW (Stop the World)

Suspending an application thread in order to collect an object reference to an application

When this phase is complete, the application thread starts again

2. Concurrent tags (CMS concurrent mark)

Starts with the object reference collected in the first phase, traversing all other object references

3. Concurrent pre-cleaning (Cms-concurrent-preclean)

Change the object reference generated by the application thread when running the second phase to update the results of the second phase

4. Re-labeling (CMS remark) will STW

Because the third phase is concurrent, the object reference may change further, so the application thread is paused again to update the changes

And make sure that a correct object reference view is made before the actual cleanup is done

5. Concurrent Cleanup (CMS concurrent sweep)

All objects that are no longer referenced will be removed from the heap

6. Concurrent resets:

Collectors do some finishing work so that the next GC cycle can have a clean state

Two challenges for CMS:

1. Heap Fragments

The CMS collector defaults to no mechanism for defragmenting. So there might be a situation like this:

Even if the total heap size is far from depleted but cannot allocate the object, simply because there is not enough contiguous space to fully accommodate the object.

When this happens, the JVM triggers the full GC

2. High rate of object allocation

Gets an object instance more frequently than the collector cleans up dead objects in the heap

concurrency mode failure: There is not enough free space in the old age to accommodate an object raised from the younger generation.

The JVM performs heap defragmentation at this point: triggers the full GC

When one of these situations arises, it is often proved that there are a large number of unnecessary objects in the old age.

One possible way to do this is to increase the size of the younger generation's heap (increase the number of survior areas) to prevent young generations of short life-cycle objects from advancing into the old age.

Other methods: Use Jmap and jhat to analyze excessive object allocations, identify these objects, and ultimately reduce the application of these objects.