The original link

The figure above lists seven types of garbage collectors that work in different generations, and can be used in combination if there is a connection between two collectors. The region in which the collector is located indicates whether it belongs to the young generation or the old generation

A collector of the younger generation

Serial collector

Simple, efficient and small memory consumption, suitable for the client mode of virtual machine

The collector is a single threaded operation. This means that while it is garbage collecting, it must pause all other worker threads until it finishes collecting. The running process of Serial and Serial Old collectors is as follows:

ParNew collector

The multithreaded version of the Serial collector behaves like the Serial collector, except that multiple threads are used simultaneously for garbage collection. Prior to JDK1.7, the Serial collector was the only one that worked with the CMS collector

Parallel Scavenge collector

A throughput – based collector that supports parallel collection just like the Parnew collector. Two parameters are used to precisely control throughput, and an adaptive tuning strategy is also supported

  • -XX:MAXGCPauseMillis: Controls the maximum garbage collection pause. Allowing a number greater than 0 to be set, the collector will do its best to ensure that memory is collected for no more than the set time
  • -XX:GCTimeRatio: Configure throughput size. The value of the argument is an integer greater than 0 and less than 100.

It belongs to the old collector

Serial Old collector

An older version of the Serial collector, which is a single-threaded collector, uses a mark-compression algorithm. In server-side mode, there are two uses:

  • Available in JDK5 and earlier versions with the Parallel Scavenge collector
  • As a fallback in the event of a CMS collector failure

Parellel Old collector

An older version of the Parellel Scavenge collector that supports concurrent collection by multiple threads and is based on a mark-compression algorithm.

CMS Collector (Concurrent Mark Sweep)

Is a collector to obtain the shortest collection pause time as the goal, based on mark-sweep algorithm. The whole process is divided into four steps:

  1. Initial markup: Marks the objects that GC ROOTS can relate to directly
  2. Concurrent markup: Traverse the entire object graph, starting with the objects directly related to the GC Roots
  3. Relabeling: The part of the object that modifies the concurrent markup during which the markup has changed as the user thread continues to operate
  4. Concurrent purge: Cleanup objects that the delete mark phase determines are dead

Disadvantages:

  1. Due to the mark-sweep algorithm, fragmentation occurs after the collection is complete. Too much fragmentation can cause a lot of trouble with large object allocation, and Full GC has to be triggered early because there is a lot of space left but no contiguous space large enough to allocate objects

Garbage First (G1)

Since the Java version I’m using is 1.8.0_231, the default young collector is Parallel Scavenge and the Old collector is Parellel Old

The G1 collector is the default configuration in Java9 and can only be implemented on Java8 using G1 by adding -XX:+UseG1GC

Operation process of G1:

  1. Initial markup: Marks the objects that GC Roots can associate with and modifies the value of the TAMS pointer so that the next stage of concurrent execution by user threads can correctly allocate objects among the available Ragion
  2. Concurrent labeling: Rachability analysis is performed on the objects in the heap starting with GC Roots, scanning the entire object graph in the heap
  3. Final mark: A short pause for the user thread to process the records that remain after the concurrency phase has ended
  4. Filter Collection: Update Ragion statistics and plan the collection based on the user’s expected pause time

G1 related articles:

Explore the G1 garbage collector JVM G1 garbage collection summary