This article introduces seven common garbage collectors in HotSpot virtual machine, as follows:

1. Serial collector

Is the oldest of the new generation of garbage collectors. It is characterized by single-threaded execution and needs to suspend all other threads while working.

It has the advantage of being simple and efficient, with little extra memory consumption.

Currently it is the HotSpot virtual machine that runs the default next-generation garbage collector in client mode.

2. ParNew collector

Think of it as a multithreaded parallel version of Serial.

Currently, ParNew and Serial are the only new-generation collectors that can be used with CMS. When the CMS garbage collector is started with the -xx: +UseConcMarkSweepGC parameter, ParNew is selected as the new generation garbage collector by default.

3. Parallel Scavenge

It is a new generation of garbage collector focusing on Throughput.

Throughput = Time running user code/(Time running User code + time running garbage collection)

Parallel Scavenge provides two parameters for accurate control of throughput, which are:

  • -XX: MaxGCPauseMillis: The maximum garbage collection pause time, which is a number of milliseconds greater than 0 The collector will try to ensure that the collection time does not exceed the value set by the user;
  • -XX: GCTimeRatio: Indicates the throughput size. Integers in the range of (0, 100) are allowed. The default value is 99, indicating the maximum allowed value1 over 1 plus 99 is equal to 1%Garbage collection time;

Parallel Scavenge also provides a parameter XX: +UseAdaptiveSizePolicy to enable an adaptive adjusting policy. After the policy is enabled, the virtual machine collects performance monitoring information according to the running status of the current system and dynamically adjusts parameters such as the generation size (-xmn), Eden zone and Survivor zone ratio (-xx: SurvivorRatio) to provide the most appropriate pause time or maximum throughput. In situations where manual optimization is difficult, an adaptive tuning strategy is a good choice.

4. Serial Old collector

Is an older version of the Serials collector. It is also the default old-fashioned garbage collector that the HotSpot virtual machine runs in client mode. In server mode, it is typically used in conjunction with the Parallel scexploiture collector, or as a preparation solution if the CMS collector fails.

5. Parallel Old collector

It’s an old version of the Parallel Scavenge.

In a throughput focused scenario, the combination of Parallel Scavenge and Parallel Old is preferable. Also, this combination is selected by default for Java8.

# Run the Java -xx :+PrintCommandLineFlags -version -xx :InitialHeapSize=268435456 
-XX:MaxHeapSize=4294967296+ PrintCommandLineFlags - - XX: XX: XX: + UseCompressedClassPointers - # + UseCompressedOops UseParallelGC says use of the Parallel Scavenge + Parallel Old combination -xx :+UseParallelGC Java version"1.8.0 comes with _221"
Java(TM) SE Runtime Environment (build 1.8. 0 _221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)
Copy the code

6. CMS collector

Concurrent Mark Sweep is a collector with the goal of obtaining the shortest collection pause time. It is implemented based on the “mark-sweep” algorithm.

Its working process is complex, divided into the following four steps:

  • Initial tag: tagGC RootObjects that can be directly associated with, which is fast, but requiresStop The World, STW;
  • Concurrency flag: fromGC RootThe directly associated object of starts traversing the entire memory, which takes a long time but does not require a pause in the user thread;
  • Re-marking: The mark record used to correct the part of the object whose mark changed as the user program continued to operate during concurrent marking is still requiredSTW;
  • Concurrent cleanup: Clean up dead objects judged by the deletion phase, which can be executed concurrently with the user thread;

CMS is an excellent “low-pause” garbage collector, but it has several disadvantages:

  • In the concurrent phase, although the execution of user threads does not stop, it still occupies system resources and reduces application running efficiency.

  • The garbage collection thread executes concurrently with the user thread, which means that some resources need to be reserved for the user thread. After JDK6, the default CMS startup threshold is 92%, which means that user threads are left with 8% of memory resources. When this memory resource is insufficient, a “Concurrent Mode Failure (CMF)” occurs. CMS provides a back-up mechanism to handle CMF: freezing the execution of user threads and temporarily enabling the Serial Old collector to re-run the Old garbage collection. But this can also lead to longer pauses;

  • CMS is a garbage collector based on a “mark-clean” algorithm, which generates a lot of memory fragmentation. When allocating memory space for a large object, it is often the case that a Full GC has to be triggered in advance because there is still a lot of free space in the old age, but the current object cannot be allocated in sufficient continuous space. Although CMS provides two optimization parameters, the actual effect is not ideal:

    • -XX: +UseCMSCompactAtFullCollection: Enabled by default to enable the consolidation process of memory fragmentation if the CMS collector has to perform Full GC. The process has to beSTW, resulting in a longer pause time;
    • - XX: CMSFullGCsBeforeCompaction: requires the CMS collector not to clean up the space after a number of times (depending on the parameter value)Full GCAfter that, the next entryFull GCIt’s going to be defragmented. The default value is 0, indicating each entryFull GCAre defragmented;

7. G1 collector

Garbage First. The design goal is to achieve the highest throughput possible with controllable latency.

It uses the Mixed GC mode and can be used for Collection against any part of the heap memory. The measure is no longer which generation the memory area belongs to, but which memory contains the most garbage and the most collection revenue.

G1 divides the Java heap into separate equal-sized regions called regions. Each Region has acted as the Eden, Survivor, or old age space as required. In addition, a Region is the smallest unit of a single collection. G1 keeps track of the garbage “value” of each Region, maintains a priority list in the background, and recollects the Region with the largest value first according to the collection pause time set by the user (-xx: MaxGCPauseMillis, 200 milliseconds by default).

Some special regions are identified as Humongous regions, which are used to store large objects. (G1 identifies objects whose size exceeds half of a Region’s capacity as large objects.) Oversized objects that exceed the capacity of the entire Region are stored in multiple contiguous Humongous regions. For the most part, G1 treats Humongous Region as part of the old age.

The operation of the G1 collector can be roughly divided into the following four steps:

  • Initial markup: Simply mark the objects that GC Roots can directly relate to and modify the value of the TAMS pointer. This phase involves pausing the user thread, but it takes a short time;

    G1 allocates two Pointers, called TAMS, to each Region. The newly allocated object address must be in between the two Pointers.

  • Concurrency markup: Reachability analysis of objects in the heap starting with GC Root, recursively scanning the object graph throughout the heap to find objects to reclaim, this phase takes a long time, but can be executed concurrently with the user program.

  • Final flag: Another short pause on the user thread to process the last few records left after the concurrent phase has ended.

  • Filter recycling: Update Region statistics, sort the collection value and cost of each Region, and make a collection plan based on the desired pause time. You can select any number of regions for collection, and then copy the living objects in the selected Region to empty regions. Clean up all the space in the old Region. The user thread needs to be paused.