Note: Based on JDK1.7 Update 14.

Serial collector

The Serial collector is the most basic and oldest collector, and until JDK1.3.1 was the only choice for next-generation collections of virtual machines. The Serial collector is a single-threaded collector. Note that “single-threaded” here does not mean that it uses only one CPU or one collector thread to complete the garbage collection, but that it must suspend all other worker threads while it does the garbage collection until the collection is complete. Stop The World. The collector runs as follows:



Features:

Simple and efficient, for a single-CPU constrained environment, Serial collector concentrates on garbage collection because it does not have the overhead of thread interaction, so it can naturally achieve the highest single-threaded collection efficiency.For virtual machines running in Client mode.

ParNew collector

The ParNew collector is a multithreaded version of the Serial collector and behaves exactly like the Serial collector, except that it uses multiple threads for garbage collection. The schematic diagram of the Parnew collector is as follows:



The Parnew collector is for the next generation of collectors for virtual machines running in Server mode. And it works with the CMS collector.

Parallel Scavenge collector

The Parallel Scavenge collector is a new generation collector that uses a time copy algorithm. It is a Parallel multi-threaded collector. The goal of the Parallel Scavenge collector is to achieve a manageable throughput. Throughput refers to the ratio of CPU time spent running user code to total CPU elapsed time, i.e. :

Throughput = time to run user code/(time to run user code + garbage collection time).

For example, the virtual machine runs for a total of 100 minutes, of which garbage collection takes 1 minute and the throughput is 99%. Shorter pause time is more suitable for programs that need to interact with users. Good response speed can improve user experience, while high throughput can make efficient use of CPU time to complete the program’s computing tasks as soon as possible, which is mainly suitable for backstage operations without too much interaction.

Serial Old collector

The Serial Old collector, an older version of the Serial collector, is also a single-threaded collector that uses a mark-and-tidy algorithm. The schematic diagram is as follows:

This collector is also intended for use by virtual machines in the Client mode. If you are in Server mode, you can also use it for two purposes:

  • Used with the Parallel Scavenge collector in JDK1.5 and earlier;
  • As a fallback plan for the CMS collector, used in the event of Concurrent Mode Failure for Concurrent collections.

Parallel Old collector

Parallel Old is an older version of the Parallel Scavenge collector that uses multithreading and a “mark-and-tidy” algorithm. The schematic diagram is as follows:

CMS collector

A CMS collector is a collector whose goal is to obtain the shortest collection pause time. It is based on the “mark – clear” algorithm. Its operation process is divided into four steps:

  1. Initial tag The initial tag requires “Stop The World”. The initial markup is just a quick markup of the objects that GC Roots can relate to directly.
  2. Concurrent Tagging The concurrent tagging phase is the process of GC Roots Tracing.
  3. Relabelling The relabelling phase requires “Stop The World”. This phase corrects the mark record for the part of the object during concurrent marking that has changed as the user program continues to operate. The pause time in this phase is generally slightly longer than the initial marking phase, but shorter than the concurrent marking period.
  4. The phase of concurrent purge is to purge the marked object and reclaim memory.

The schematic diagram is as follows:

Advantages: Concurrent collection, low pauses.

Disadvantages:

  1. The CMS collector is very sensitive to CPU resources.
  2. The CMS collector is unable to handle floating garbage and may fail in “Concurrent Mode Failure” causing another Full GC to occur. Under the default Settings of JDK1.5, CMS collector when old s use 68% of the space will be activated, if in the application of Laos s growth is not too fast, can raise the parameters appropriately – XX: CMSInitiatingOccupancyFraction value to improve trigger percentage, In order to reduce the number of memory collection for better performance. In JDK1.6, the starting threshold for the CMS collector has been raised to 92%.
  3. CMS is based on the “mark-clean” algorithm, and there may be a large amount of debris space at the end of collection. When there is too much space debris, it will cause a lot of trouble to allocate large objects. It is often the case that there is a lot of space left in the old age, but the current object cannot be allocated, and a Full GC has to be triggered early. In order to solve this problem, the CMS collector provides a switch parameters: – XX: + UseCMSCompactAtFullCollection, this parameter is the default is open, can’t used at the top of the CMS to Full GC is open memory fragments merging finishing process.

G1 collector

The G1 (Garbage-First) collector is a Garbage collector for server-side applications. It has the following characteristics:

  • Parallelism and concurrency
  • Generational collection
  • Space to sort out
  • Predictable pauses

The G1 collector divides the entire Java heap into equal-sized independent regions. Although the concepts of new and old ages are retained, new and old ages are no longer physically isolated; they are all part of a collection of regions that do not require contiguity. In the G1 collector, object references between regions and between new and old objects in other collectors use Remembered Set to avoid full heap scans. Each Region in G1 has a corresponding Remembered Set. When the virtual machine finds that the program writes the data of Reference type, it will generate a Write Barrier to temporarily interrupt the Write operation. Check whether the referenced object is in a different Region. If so, the relevant Reference information is recorded to the Remembered Set of the Region of the referenced object through CardTable to ensure that there will be no full-heap scan and no omissions.

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

  1. Initial tagging The initial tagging phase simply marks the objects that the GC Roots can relate to directly and modifies the TAMS(Next Top at Mark Start) values so that the Next phase of concurrent user programs can create new objects in the correctly available Region. This phase requires a pause thread. But it takes a short time.
  2. Concurrent markup The concurrent markup phase starts with the GC Root and performs a reachable analysis of the objects in the heap to find the surviving objects. This phase takes longer, but can be executed concurrently with the user thread.
  3. The final mark is to correct the part of the mark record that has changed during concurrent marking because the user program continues to execute. The virtual machine records object changes during this time in thread Remembered Set Logs. The final markup phase requires merging the data of Remembered Set Logs into the Remembered Set. This phase requires pausing threads, but can be executed in parallel.
  4. Screening and collection In the screening and collection stage, the recovery value and cost of each Region are sorted first, and the recovery plan is specified according to the expected GC time of the user.

The G1 collector runs as follows: