Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the garbage collectors of Java". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what are the garbage collectors of Java.

Let's first review the garbage collector (HotSpot JVM) of mainstream Java. This article focuses on heap garbage collection. The heap is broken down into three smaller parts. Specifically divided into: the new generation, the old age, the lasting generation.

Most of the newly generated objects are placed in the Eden area. When the Eden area is almost full, JVM will trigger Young GC because it cannot apply for memory, carry out garbage collection in the Eden area + Survivor area with objects (set to S0 area), and copy the surviving objects to an empty Survivor (S1) with a copy algorithm, when the Eden area is emptied and the other Survivor S0 is also empty. The next time Young GC is triggered to reclaim Eden+S0, the surviving object is copied to S1. The new generation of garbage collection is simple, rough and efficient.

If the Survivor area is found to be full, copy these objects to the old area or the Survivor is not full but some objects are sufficient Old, and also to the Old area (each Young GC keeps the Survivor area alive by a value of + 1, up to the threshold). Garbage collection (Young GC) is also performed in the Old area, and Major GC is accompanied by Young GC at least once, which is generally more than ten times slower than Young GC.

JVM cannot apply for memory in the Old area and will perform Full GC. The Old area generally uses the Concurrent-Mark-Sweep strategy to reclaim memory. Summary: the Java garbage collector is an "adaptive, generational, stop-copy, mark-clean" garbage collector with disadvantages:

STW (Stop-The-World) appears in the process of GC. If there are too many objects in the Old area, STW consumes a lot of time.

The CMS collector is sensitive to CPU resources.

The CMS collector cannot handle floating garbage, and a "Concurrent Mode Failure" failure may result in another Full GC generation.

CMS causes memory fragmentation problem

# compare

Serial collector

The Serial collector is the most basic and oldest collector in the JAVA virtual machine, and it was the only choice for the new generation of JAVA virtual machine collection before JDK 1.3.1. The Serial collector is a single-threaded collector, but its "single-threaded" meaning does not only mean that it will use only one CPU or one collection thread to complete garbage collection, but more importantly, when it carries out garbage collection, it must pause all other worker threads until its collection is finished. Until JDK1.7, the Serial collector is still the default new generation collector for JAVA virtual machines running in Client mode. It also has advantages over other collectors: simple and efficient (single-threaded ratio with other collectors). For an environment that limits a single CPU, the Serial collector can naturally achieve the highest single-threaded collection efficiency because it has no overhead of thread interaction. In the user's desktop application scenario, the memory allocated to the virtual machine management is generally not very large, and the new generation that collects tens of megabytes or even one or two hundred megabytes of memory (only the memory used by the new generation, desktop applications basically will not be larger). The pause time can be controlled within tens of milliseconds or more than 100 milliseconds, as long as it does not occur frequently, this pause is acceptable. Therefore, the Serial collector is a good choice for virtual machines running in Client mode.

PS: how to enable the Serial collector-XX:+UseSerialGC such as: Xms30m-Xmx30m-Xmn10m-XX:+UseSerialGC-XX:+PrintGCDetails-XX:+UseSerialGC is the Serial collector. Xms30m-Xmx30m specifies that the fixed size of the JAVA virtual machine is 30m, which means that the space of the new generation of JAVA is 10m.

Parallel (parallel) collector

This is the default collector for JVM. Like its name, its biggest advantage is the use of multiple threads to scan and compress the heap. The serial collector stops all other worker threads (stop-the-world) during GC, and CPU utilization is the highest, so it is suitable for applications that require high throughput (throughput), but the pause time (pause time) is longer, so it is not suitable for web applications, because this means that the user wait time will be longer. The parallel collector can be understood as multithreaded serial collection, which uses multithreaded GC on the basis of serial collection, which well makes up for the shortcomings of serial collection and can greatly shorten the pause time (such as the height of pause time shown in the following figure, concurrency is shorter than parallel), so for areas with small space (such as young generation), the pause time of parallel collector is very short, high recovery efficiency, suitable for high-frequency execution. Comparison of figure 1.Serial collector and Parallel/ Throughput (parallel) collector

CMS collector

The CMS (Concurrent Mark Sweep) collector is implemented based on the mark-and-clear algorithm, which uses a multi-threaded algorithm to scan the heap (mark) and reclaim (clear) unused objects found. The whole process is divided into six steps, including: initial marking (CMS initial mark)

Concurrent tagging (CMS concurrent mark)

Concurrent pre-cleaning (CMS-concurrent-preclean)

Relabel (CMS remark)

Concurrent cleanup (CMS concurrent sweep)

Concurrent reset (CMS-concurrent-reset)

The two steps of initial tagging and relabeling still require "Stop The World".

The initial tag only marks the objects to which GC Roots can be directly associated, which is very fast.

The concurrent marking phase is the process of GC Roots Tracing.

The purpose of the relabeling phase is to correct the markup records of the objects whose markup changes are caused by the continued operation of the user program during the concurrent tagging period, and the pause time in this phase is generally slightly longer than that in the initial tagging phase, but much shorter than the concurrent tagging time. Other actions are concurrent.

It should be noted that the CMS collector cannot handle floating garbage (Floating Garbage), and a "Concurrent Mode Failure" failure may result in another Full GC generation. Since the user thread is still running during the CMS concurrency cleanup phase, new garbage will naturally be generated with the running of the program. This garbage appears after the marking process, and CMS cannot dispose of it in this collection, so it has to wait for the next GC to clean it up. This part of the garbage is called "floating garbage". It is also because the user thread still needs to run in the garbage collection phase, that is, it also needs to reserve enough memory space for the user thread to use, so the CMS collector can not wait until the old age is almost completely filled up like other collectors, and needs to reserve some space for the program operation when the concurrent collection is used. By default, the CMS collector will be activated after 68% of the space is used in the old years. This is a conservative setting. If the growth is not too fast in the old age of the application, you can appropriately increase the trigger percentage by increasing the value of the parameter-XX:CMSInitiatingOccupancyFraction, so as to reduce the number of memory reclaims for better performance. If the memory reserved during the CMS run does not meet the needs of the program, there will be a "Concurrent Mode Failure" failure, when the virtual machine will start a backup plan: temporarily enable the Serial Old collector to restart the old garbage collection, so the pause time is very long. So setting the parameter-XX:CMSInitiatingOccupancyFraction too high will easily lead to a large number of "Concurrent Mode Failure" failures and performance degradation.

Another drawback is that CMS is a collector based on the "mark-clear" algorithm, which means that a large amount of space debris is generated at the end of the collection. When there is too much space debris, it will bring a lot of trouble to the allocation of large objects, often there is still a lot of space left in the old age, but can not find enough continuous space to allocate the current objects, so Full GC has to be triggered in advance. To solve this problem, the CMS collector provides a-XX:+UseCMSCompactAtFullCollection switch parameter to attach an additional defragmentation process free of charge after "enjoying" the Full GC service, which is not concurrent. The problem of space debris is gone, but the pause has to be longer. Virtual machine designers also provide another parameter-XX: CMSFullGCsBeforeCompaction, which is used to set the number of times an uncompressed FullGC is executed, followed by one with compression.

Another disadvantage of this algorithm compared with parallel collectors is that it uses more CPU for throughput, and scans and collections are performed by using multiple threads in order to provide a better experience for the application. Running for a long time in this situation will bring the application to a standstill, and you can use increased space in exchange for efficient operation. However, the use of this algorithm is not the default. You must specify XX: + USeParNewGC to use it. If you can provide more CPU resources to avoid application pauses, then you can use the CMS collector. Suppose your heap size is less than 4 Gb and you must allocate resources greater than 4 GB.

G1 collector

G1 garbage collector has better support for heaps larger than 4G after JDK7 update 4. G1 is a server-side garbage collector for multi-processors with large memory, and its goal is to meet the requirements of garbage collection pause time as much as possible while achieving high throughput. G1 performs some global operations in Java heap space (such as global tags) concurrently with application threads, thus reducing the interruption ratio of Java heap space. (translator's note: it can be simply understood as reducing the proportion of Stop-the-World time).

It has two significant improvements over the previous CMS collector: one is that the G1 collector is based on the tag-demarcation algorithm, that is, it does not generate space debris, which is very important for long-running applications. Second, it can precisely control the pause, which allows users to specify clearly that the time spent on garbage collection should not exceed N milliseconds in a time period of M milliseconds, with some of the characteristics of real-time Java (RTSJ) garbage collectors.

First, the Java heap space is divided into areas of equal size (region), each of which is a piece of contiguous memory space in the virtual machine. G1 determines the surviving objects in the entire Java heap space by executing concurrent global tags. After the marking phase is complete, G1 knows which areas are basically free. Priority is given to recycling these areas when reclaiming memory, which usually reclaims a considerable amount of memory. That's why it's called Garbage-First. As the name implies, G1 is concerned with the recycling and sorting of certain areas where objects are likely to be completely recycled. Moreover, G1 uses a pause time prediction model to control the pause time within the user-specified pause time, and selects the appropriate area to reclaim memory according to the user-specified pause time.

After G1 has identified the area that can be recycled, it is the evacuation phase. At this stage, objects are copied from one or more areas to a single area, and memory is demarcated and freed. This phase occurs in parallel with multiple threads on multiple processors, thus reducing pause time and improving throughput. G1 continuously reduces fragmentation during each garbage collection process and is able to control the pause time within a certain range. These can no longer be done by previous garbage collectors. For example, the CMS collector does not do memory consolidation. The ParallelOld collector simply tidies up the entire Java heap space, which results in a considerable pause time.

Thank you for your reading, these are the contents of "what are the garbage collectors of Java". After the study of this article, I believe you have a deeper understanding of what the garbage collectors of Java have, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.