Garbage Collector 1 of JVM Garbage Collection Series

sequence

"Black hair doesn't know how to study early, but white hair regrets studying late"

introduction

This article will introduce several common garbage collectors in HotSpot, such as: Serial, ParNew, Parallel Scavenge, CMS, etc.

Reference book: "In-depth understanding of Java Virtual Machine"

Personal java knowledge sharing project - gitee address

Personal java knowledge sharing project - github address

Classification of Garbage Collectors

If the collection algorithm is the methodology of memory recovery, then the garbage collector is the specific implementation of memory recovery. The Java virtual machine specification does not specify how the garbage collector should be implemented. Therefore, the garbage collectors provided by different manufacturers and different versions of virtual machines may be very different, and generally provide parameters for users to customize according to their own needs. The collectors used in each age are combined based on the application characteristics and requirements, that is to say, what garbage collector the jvm uses can be customized by the user. If the user does not configure, the default garbage collector in JAVA1.8: Parrallel Scanvenge+ParallelOld

The figure below shows 7 collectors that act on different generations. If there is a connection between the two collectors, it means that they can be used together. The area where the virtual machine is located indicates whether it belongs to the new generation collector or the old generation collector.

Looking at the picture above, you may have a question, why the virtual machine provides so many garbage collectors, then here you need to make a clear point: although we are comparing various collectors, it is not to pick the best one collector, because until now there is no best collector, let alone a universal collector, so we only choose the most suitable collector for specific applications.

Evaluate GC performance indicators:

• Throughput: the ratio of the time spent running user code to the total running time (total running time: program running time + memory recovery time) (emphasis)
• Garbage collection overhead: the complement of throughput, the ratio of time spent in garbage collection to total running time
• Pause time: The time during which the program's worker threads are suspended while performing garbage collection. (emphasis)
• Collection Frequency: How often collection operations occur relative to the execution of the referencing program
• Memory occupation: the memory size occupied by the Java heap area. (emphasis)
• Fast: the time it takes for an object to be recycled from its birth

Serial collector: Serial collection

The Serial collector is the most basic and oldest garbage collector. Before JDK1.3, the only option to recycle the new generation. The Serial collector is used as the default new generation garbage collector in Client mode in HotSopt. The Serial collector performs memory reclamation using copy algorithms, serial reclamation, and the "Stop-the-World" mechanism. In addition to the young generation, the Serial collector also provides the Serial Old collector for performing old generation garbage collection. The Serial Olds collector also uses the serial return and "Stop-the-World" mechanism, but the memory recovery algorithm uses the mark-compression algorithm. Serial Old Trial Run In Client mode, the default garbage collector for the old age, Serial Old, has two main uses in Server mode:

1. Work with the new generation of Parallel Scavenge
2. As a fallback garbage collection scheme for the old generation CMS collector.

This collector is a single-threaded collector, but its "single-threaded" meaning not only means that it will only use one CPU or one collection thread to complete the garbage collection work, but more importantly, when it performs garbage collection, it must Pause all other worker threads until it collects (Stop The World)

Advantages: Simple and efficient (compared to the single-thread of other collectors). For an environment limited to a single CPU, the Serial collector has no thread interaction overhead, so concentrating on garbage collection can naturally obtain the highest single-thread collection efficiency. (A virtual machine running in Client mode is a good choice)

Disadvantage: When in STW, programs running on the virtual machine cannot provide services (this is unbearable!!!)

In the HotSpot virtual machine, use the -XX:UseSerialGC parameter to specify a serial collector for both the young generation and the old generation. It is equivalent to the use of Serial GC in the new generation and the use of Serial Old GC in the old generation. This kind of garbage collector only needs to be understood. Now it is basically the garbage collector. Because this garbage collector is only used in limited single core. It's not single core anymore.

Application scenario: single-core embedded device

ParNew collector: Parallel collection

If Serial GC is a single-threaded garbage collector in the young generation, then the ParNew collector is a multi-threaded version of the Serial collector. Par is the abbreviation of Parallel, New: can only deal with the new generation. The ParNew collector also uses the copy algorithm and "Stop The World" mechanism in the young generation. ParNew is the default garbage collector for the new generation of many JVMs running in Server mode.

Apart from multi-threaded collection, the ParNew collector does not have much innovation compared with the Serial collector, but it is the preferred new generation collector for many virtual machines running in Server mode, one of which is the same as The reason that performance is irrelevant but important is that, besides the Serial collector, it is currently the only one that works with the CMS collector. Unfortunately, CMS, as the collector of the old generation, cannot work with the existing new generation collector Parallel Scavenge in JDK 1.4.0, so when using CMS to collect the old generation in JDK 1.5, the new generation can only Choose one of the ParNew or Serial collectors. The ParNew collector is also the default new generation collector after using the -XX:+UseConcMarkSweepGC option, or you can use the -XX:+UseParNewGC option to force it.

Then a question arises spontaneously: Since the ParNew collector is based on parallel recycling, can it be concluded that the recycling efficiency of the ParNew collector will be more efficient than the Serial collector in any scenario?

Answer: The ParNew collector runs in a multi-CPU environment. Because it can make full use of the advantages of physical hardware resources such as multi-CPU and multi-core, it can complete garbage collection faster and improve the throughput of the program. But in a single CPU environment, the ParNew collector is not more efficient than the Serial collector. Although the Serial collector is based on serial recycling, since the CPU does not need to switch tasks frequently, it can effectively avoid some additional overhead generated during multi-thread interaction. Because apart from Serial, currently only ParNew GC can work with the CMS collector.

Features:

• For the new generation, the number of collections is frequent, and the use of parallel methods is efficient.
• For the old generation, the number of recycling is small, and the serial method is used to save dimensions (the CPU needs to switch threads in parallel, and serial can save the resources of switching threads)

Parallel Scavenge collector: throughput priority

In addition to the ParNew collector in the Young Generation of HotSpot which is based on parallel recycling, the Parallel Scavenge collector also adopts the replication algorithm, parallel recycling and "Stop the World" mechanism

So the principle of the Parallel Scavenge collector is the same as that of ParNew, so what is the function of this collector?

1. Unlike the ParNew collector, the goal of the Parallel Scavenge collector is to achieve a controllable throughput (Throughput), which is also known as a throughput-first garbage collector.
2. The adaptive adjustment strategy is also an important difference between Parallel Scavenge and ParNew.
3. High throughput can use CPU time efficiently and complete the calculation tasks of the program as soon as possible. It is mainly suitable for tasks that operate in the background without much interaction. Therefore, it is commonly used in server environments. For example, those applications that perform batch processing, order processing, payroll, scientific computing.

Parameter configuration:

• -XX:+UseParallelGC manually specifies that the young generation uses the Parallel parallel collector to perform memory recovery tasks.
• -XX:+UseParallelOldGC manually specifies that the old generation is to use the parallel collection collector.
  • Used in the new generation and the old generation respectively. By default jdk8 is enabled.
  • The above two parameters, one is enabled by default, and the other will also be enabled (mutual activation)
• -XX:ParallelGCThreads Set the number of threads for the young generation parallel collector. In general, it is best to be equal to the number of CPUs to avoid excessive number of threads affecting garbage collection performance.
  • By default, when the number of CPUs is less than 8, the value of ParallelGCThreads is equal to the number of CPUs.
  • When the number of CPUs is greater than 8, the value of ParallelGCThreads is equal to 3+[5*CPU_Count]/8].
• -XX:MaxGCPauseMillis sets the maximum pause time of the garbage collector (ie STW time). The unit is milliseconds.
  • In order to control the pause time within MaxGCPauseMillis as much as possible, the collector will adjust the Java heap size or some other parameters when working. For users, the shorter the pause time, the better the experience. But on the server, we focus on high concurrency and overall throughput. So the server fits in Parallel, for control. (Be careful when using this parameter)
• -XX:GCTimeRatio The ratio of garbage collection time to the total time (1/(N+1)).
  • Value range (0,100). The default value is 99, that is, the garbage collection time does not exceed 1%
  • There is a certain contradiction with the previous -XX:MaxGCPauseMillis parameter. The longer the pause time, the easier it is for the Ratio parameter to exceed the set ratio.

Serial Old collector: acting on the old generation

Serial Old is the old version of the Serial collector, which is also a single-threaded collector, using the "mark-sort" algorithm. The main significance of this collector is also to use it for virtual machines in Client mode. If it is in Server mode, it has two main uses: one is to use it with the Parallel Scavenge collector in JDK 1.5 and earlier versions (need to explain, the Parallel Scavenge collector architecture itself has PS MarkSweep collection Collector for old age collection, not directly using the Serial Old collector, but this PS MarkSweep collector is very close to the implementation of Serial Old), another use is as a backup plan for the CMS collector, when concurrent collection occurs in Concurrent Mode Use when Failure

Parallel Old collector: acting on the old generation

Parallel Old is an old version of the Parallel Scavenge collector, which uses a mark-compression algorithm, but is also based on parallel recycling and the "Stop-The-World" mechanism. This collector was only provided in JDK 1.6. Before that, the new generation of Parallel Scavenge collectors had been in an awkward state. The reason is that if the new generation chooses the Parallel Scavenge collector, the old generation has no choice but the Serial Old (PS MarkSweep) collector (remember that the Parallel Scavenge collector cannot work with the CMS collector?). Due to the "drag" of the Serial Old collector in the server-side application performance, the use of the Parallel Scavenge collector may not be able to maximize the throughput of the overall application, because the single-threaded old collection cannot be fully utilized The processing power of multiple CPUs of the server, in an environment where the old generation is large and the hardware is relatively advanced, the throughput of this combination may not even be as powerful as the combination of ParNew and CMS.

CMS Recycler: Low Latency

During the JDK1.5 period, HotSpot withdrew from an almost epoch-making garbage collector in a strong interactive application: the CMS (Concurrent-Mark–Sweep) collector, which is the first real garbage collector in the HotSpot virtual machine. Concurrent collector, which for the first time allows garbage collection threads to work concurrently with user threads.

The focus of the CMS collector is to minimize the pause time of user threads during garbage collection. The shorter the pause time (low latency), the more suitable for programs that interact with users, and good response speed can improve user experience. (At present, a large part of Java applications are on the server side of the Internet website or B/S system. This type of application pays special attention to the response speed of the service. It is hoped that the system pause time will be the shortest to bring a better experience to users. CMS The collector is very suitable for the needs of this type of application)

The garbage collection algorithm of CMS adopts the mark-clear algorithm, and will also "Stop-the-World". Its operation process is more complicated than that of the previous collectors. The whole process is divided into 4 steps, including:

1. Initial mark (Initial Mark) stage: In this stage, all worker threads in the program will be temporarily suspended due to the "Stop-the-World" mechanism. The main task of this stage is only to mark that GC Roots can directly the associated object. All application threads that were suspended are resumed once marking is complete. Since the directly associated objects are relatively small, the speed here is very fast.
2. Concurrent Mark phase: The process of traversing the entire object graph starting from the directly associated objects of GC Roots. This process takes a long time but does not need to pause the user thread, and can run concurrently with the garbage collection thread. (The entire marking process takes the longest)
3. Remark (Remark) phase: Since in the concurrent marking phase, the worker thread of the program will run concurrently or cross-running with the garbage collection thread, so in order to correct the part of the object that is marked due to the continued operation of the user program during the concurrent marking period Mark records, the pause time of this phase is usually slightly longer than the initial marking phase, but also much shorter than the concurrent marking phase.
4. Concurrent Sweep stage: This stage cleans up and deletes the dead objects judged by the marking stage, and releases memory space. Since there is no need to move surviving objects, this stage can also be concurrently used by user threads (after this stage, there will be an operation to reset the thread).

advantage:

1. Concurrent collection, low latency

Disadvantages:
2. Memory fragmentation will occur, resulting in insufficient space available to user threads after concurrent clearing. In the case that large objects cannot be allocated, Full GC has to be started in advance.
3. The CMS collector is very sensitive to CPU resources. In the concurrency stage, although it will not cause users to pause, it will slow down the reference program and reduce the total throughput because it occupies a part of the thread.
4. The CMS collector cannot handle floating garbage. There may be a "Concurrent Mode Failure" failure that causes another Full GC to occur. In the concurrent marking phase, since the program's worker threads and garbage collection threads run simultaneously or cross-running, if new garbage objects are generated during the concurrent marking phase, CMS will not be able to mark these garbage, which will eventually lead to these newly generated garbage objects It has not been reclaimed in time, so the memory space that has not been reclaimed before can only be released when the next GC is executed.

Related parameter configuration:

• -XX:UseCMSCompactAtFullCollection The user specifies that the memory space should be compacted after the Full GC is executed to avoid memory fragmentation. However, since the memory compression and sorting process cannot be executed concurrently, the problem is that the pause time becomes longer.
• -XX:CMSFullGCsBeforeCompaction sets how many times Full GC is performed to compress the memory space.
• -XX:ParallelCMSThreads Set the number of CMS threads. (The number of threads started by CMS by default is (ParallelGCThreads+3)/4. ParallelGCThreads is the number of threads of the young generation parallel collector. When CPU resources are relatively tight, the performance of the application is affected by the CMS collector thread. stage can be very bad)

It should be noted that CMS is marked as Deprecate in the new features of JDK9 (JEP291). If we use the parameter -XX:UseConcMarkSweepGC to open the CMS collector for the HotSpot virtual machine of JDK9 and above, the user will receive a warning Information, suggesting that CMS will be deprecated in the future. The CMS garbage collector (JEP363) has been removed when developing to JDK14. Although the CMS garbage collector is removed, if -XX:UseConcMarkSweepGC is used in JDK14, the JVM will not report an error, but will only give a warning message, but will not exit. The JVM will automatically fall back to start the JVM in the default GC mode.

After introducing the above several GC collectors, you may be a little confused. What is the difference between the three GCs, Serial GC, Parallel GC, and Concurrent Mark Sweep GC? In what scenario would it be better to use that GC strategy in our daily use?

For these questions, there is no standard answer, but if you want to minimize the use of memory and parallel overhead, please choose Serial GC. If you want to maximize the throughput of your application, choose Parallel GC. 3. If you want to minimize GC interruption or pause time, please choose CMS GC. These few strategies can solve most of the problems. Of course, if you have special usage scenarios, you need to carefully consider which GC collocation strategy to use!