Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the garbage collectors often asked by the interviewer". In the daily operation, I believe many people have doubts about the garbage collectors that the interviewers often ask. The editor consulted all kinds of materials and sorted out the simple and easy-to-use operation methods. I hope it will be helpful to answer the questions about "what garbage collectors are often asked by interviewers"! Next, please follow the editor to study!

Overview of JVM heap memory

Before we talk about the garbage collector, let's take a look at the partition of JVM heap memory, as shown in the following figure

Because the garbage collection algorithm used by the virtual machine is a generational collection algorithm, the heap memory is divided into the new generation and the old generation.

The garbage collection algorithm used by the new generation is the replication algorithm, so the new generation is divided into Eden and Survivor;. The default space size ratio is 8:2.

Survivor is divided into S0 and S1, with a space-to-size ratio of 1:1

Memory allocation and garbage collection

1. Objects are allocated first in the Eden area. If the Eden area is full, a Minor GC will be triggered.

2. Objects that survive from Eden after Minor GC will be moved to S0 area. When S0 memory is full, it will be triggered again. Objects survived in Minor GC,S0 area will be moved to S1 area, and S0 area will be idle. After S1 is full in Minor GC, those who survive are moved to S0 area again, and S1 area is idle, so GC again and again. Every time you GC, the age of the object will rise by one year. By default, you will enter the old age after reaching 15 years old. The age threshold for advancing to the old age can be set by parameter-XX:MaxTenuringThreshold.

3. If there is no room for sending objects that are promoted to the old age after Minor GC, then Full GC will be triggered (this step is not absolute, depending on the garbage collector)

The difference between Minor GC and Full GC: Minor GC refers to the garbage collection behavior that occurs in the new generation. Because objects are allocated first in the Eden area, and many objects die overnight, the trigger frequency is relatively high. Because of the replication algorithm used, the recovery speed is generally very fast. Full GC refers to the garbage collection behavior that occurred in the old years, and the speed of Full GC is generally more than 10 times slower than that of Minor GC, so JVM should not be allowed to occur Full GC frequently.

In order to better adapt to the memory conditions of different programs, JVM does not necessarily have to reach the age of 15 in order to enter the old age. If the total size of all objects of the same age in the Survivor area is more than half of the space of the Survivor area, the objects whose age is greater than or equal to this age will directly enter the old age.

Full GC trigger condition

Call System.gc () in the code

There is not enough space in the old days.

There is not enough space in the persistence area.

Note: large objects will allocate memory directly in the old years, and the size of objects can be controlled by the parameter-XX:PretenureSizeThreshold. Large objects are usually long strings or arrays. If a large group of large objects are allocated for temporary use and the life is very short, then Full GC will occur frequently, but at this time, the new generation is still free. This should be avoided when writing code, especially when creating arrays

Space guarantee

When Minor GC occurs in the new generation, JVM will first check whether the contiguous space allocated in the old era is greater than the sum of all objects in the new generation. If so, the Minor GC can be safely executed this time. If not, JVM will first check whether the parameter HandlePromotionFailure setting value allows space guarantee to fail. If allowed, JVM will continue to check whether the contiguous space allocated in the old age is larger than the average size of the previous promotion to the old age object. If it is greater than, although this time Minor GC is risky, JVM will also try a Minor GC; if it does not allow the guarantee to fail, then JVM will directly Full GC.

Although the guarantee may fail, resulting in a circle before GC, it is recommended that this parameter be turned on to avoid frequent Full GC in JVM.

Overview of garbage collector

As can be seen from the above picture:

Garbage collectors that can be used by the new generation: Serial, ParNew, Parallel Scavenge

Garbage collectors suitable for the old days: CMS, Serial Old, Parallel Old

G1 recycler is suitable for the new generation and the old age

The indication that there is a connection to each other can be used together.

CMS and Serial Old are both old recyclers. Why are they connected to each other?

Serial collector

This is a single-threaded collector, the oldest collector, and while it is doing garbage collection, other threads must pause until the garbage collection ends (Stop The World).

Although the Serial collector has the problem of Stop The World, it often performs better than other collectors in a single CPU environment with weak parallelism, because it is simple and efficient, and there is no extra thread interaction overhead. Serial is a good choice for virtual machines running in Client mode.

Use the-XX:+UseSerialGC parameter to set the new generation to use this Serial collector

ParNew collector

The ParNew collector is a multithreaded version of the Serial collector; except for using multithreading for garbage collection, everything else is the same as Serial; it starts with the same number of cores as CPU by default, and the number of threads can be set with the parameter-XX:ParallelGCThreads.

As can be seen from the figure above, except for Serial, the only collector that can be used with CMS is ParNew, so ParNew is usually the preferred new generation garbage collector running in Server mode.

Use the-XX:+UseParNewGC parameter to set the new generation to use this parallel collector

Parallel Scavenge collector

The Parallel Scavenge collector is still a new generation of multithreaded collectors using replication algorithms, which differs from other collectors in that it is mainly concerned with throughput, while other collectors focus on reducing the wait time of user threads as much as possible (shortening Stop The World time). Throughput = user thread execution time / (user thread execution time + garbage collection time). The virtual machine runs for a total of 100 minutes, of which garbage collection takes 1 minute, so the throughput is 99%.

A shorter pause time is suitable for programs that need to interact with users, and a good response can improve the user's experience. The efficient throughput can make full use of CPU time to complete the computing task as soon as possible, so the Parallel Scavenge collector is suitable for background computing task programs.

-XX:MaxGCPauseMillis can control the maximum pause time for garbage collection. You need to be careful not to think that setting this time very small can reduce the temporary time for garbage collection, which may lead to frequent GC and reduce throughput.

-XX:GCTimeRatio sets the throughput. The parameter is an integer in the range of 0-100, that is, the time taken by garbage collection. The default is 99, and the maximum time taken by garbage collection is 1%.

-XX:+UseAdaptiveSizePolicy if this parameter is enabled, there is no need for the user to manually control the parameters such as the size of the new generation and the age of promotion. JVM will enable the GC adaptive adjustment strategy.

Serial Old collector

The Serial Old collector is also a single-threaded collector that works in the old days, using a mark-finishing algorithm that can be used in conjunction with the Serial collector in Client mode.

It can be used as a backup plan for the CMS collector, and if Concurrent Mode Failure appears in the CMS, the SerialOld will act as the backup collector. (detailed description of CMS later)

Parallel Old collector

The Parallel Old collector can be used in conjunction with the Parallel Scavenge collector to achieve "throughput first". It is mainly aimed at older collectors, using a tag-collation algorithm. Priority can be given to using this combination in tasks that focus on throughput

-XX:+UseParallelOldGc sets the recycler to be used in the old days.

XX:+ParallelGCThreads sets the number of threads for garbage collection.

CMS collector

CMS collector is a kind of collector whose goal is to obtain the shortest recovery pause time. The commonly used collector in Internet websites and BAccord S architecture is CMS, because the system pauses for the shortest time and brings a better experience to users.

-XX:+UseConcMarkSweepGC sets the recycler to be used in the old days.

-XX:ConcGCThreads sets the number of concurrent threads.

CMS uses a mark-clear algorithm, which is divided into four steps:

Initialization tag

Concurrent tagging

Relabel

Concurrent cleanup

Stop The World still occurs in the two steps of initialization marking and relabeling. Initialization tags only mark objects to which GC Root can be directly associated, which is faster, and concurrent tags can be executed concurrently with user threads. The purpose of re-marking is to fix the garbage generated by user threads in the process of concurrent marking, which is slightly longer than initialization tags and much shorter than concurrent tags. For the whole process, please see the picture below.

Advantages

CMS is an excellent collector, its main advantages: concurrent collection, low pause, so the CMS collector is also known as the concurrent low pause collector (Concurrent Low Pause Collector).

Shortcoming

The CMS collector is very sensitive to CPU resources. In the concurrency phase, although it will not cause the user thread to stop, it will cause the application to slow down and the total throughput to decrease because it takes up some threads (or CPU resources). By default, the number of recycling threads started by CMS is (CPU + 3) / 4, that is, when the CPU is more than 4, the garbage collection thread has no less than 25% of the CPU resources when the collection is issued concurrently, and decreases with the increase in the number of CPU. However, when there are less than 4 CPU (for example, 2), CMS may have a great impact on user programs. If the CPU load is already large and half of the computing power is allocated to execute the collector thread, it may suddenly reduce the execution speed of user programs by 50%, which is also unacceptable.

Unable to handle floating garbage. Since the user thread is still running during the CMS concurrency cleanup phase, new garbage will naturally be generated as the program runs. This part of the garbage appears after the marking process, and CMS can no longer dispose of it in the current collection, so it has to be cleaned up at the next GC. This part of the garbage is called "floating garbage". It is also because the user thread still needs to run during the garbage collection phase, so it also needs to reserve enough memory space for the user thread to use, so the CMS collector cannot wait until the old age is almost completely filled up like other collectors. The recovery threshold can be set by the parameter-XX:CMSInitiatingoccupancyFraction. If the recovery threshold is set too high, if the allocation of large objects can not find enough space during the CMS operation, there will be a "Concurrent Mode Failure" failure. At this time, SerialOld GC will be temporarily started to restart the old collection, so the pause time will be longer.

The space debris CMS caused by the mark-clear algorithm is a collector based on the mark-clear algorithm, which means that a large number of space debris will be 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 resulting in old space surplus, but can not find enough continuous space to allocate current objects. To solve this problem, CMS provides a parameter-XX:+UseCMSCompactAtFullCollecion. If enabled, the memory defragmentation merge process is turned on when Full GC is enabled. Since the memory defragmentation process cannot be executed in parallel, the pause time will be longer. Considering that it is not appropriate for each FullGC to perform a memory defragmentation merge, CMS provides another parameter-XX:CMSFullGCsBeforeCompaction to control how many times a non-defragmented FullGC is executed, followed by a defragmented GC.

G1 collector

G1 is a garbage collector for server applications.

Parallelism and concurrency: similar to CMS, G1 can still perform garbage collection without pausing user threads to take full advantage of multicore CPU.

Generational collection: the concept of generational generation is still retained in G1, when it does not need to be used with other garbage collectors and can manage the entire heap memory independently

Spatial integration: G1 as a whole uses the tag-demarcation algorithm, and locally (Region) uses the replication algorithm, both of which mean that G1 does not need to defragment memory.

Predictable pause: allows the user to specify how long it takes to spend no more time in garbage collection within a time frame.

Region

Although the concept of the new generation and the old age is still retained in G1, the heap memory is organized in a completely different way, which divides the entire heap memory into many areas of the same size (Region), and the new generation and the old age are not physically continuous memory areas, see the following figure:

Each Region is marked with E, S, O, and H, where H does not exist in previous algorithms, which represents Humongous, which means that these Region store giant objects, and when the new object size is more than half the size of the Region, it is directly allocated in the new one or more contiguous Region and marked H. The memory size of the Region area can be specified by the-XX:G1HeapRegionSize parameter, and the size interval can only be the power of 2, such as 1m, 2m, 4m, 8m.

The GC mode of G1

New generation GC: similar to other new generation collectors, objects are allocated first in eden region. If the eden region is out of memory, it will trigger the new generation of GC, place the surviving objects in survivor region, or be promoted to old region.

Mixed GC: when more and more objects are promoted to old region, the mixed GC will be triggered when the memory utilization of the old age reaches a certain threshold. You can set the threshold percentage through the parameter-XX:InitiatingHeapOccupancyPercent, which is similar to the function of-XX:CMSInitiatingoccupancyFraction in CMS. Mixed GC will reclaim the new generation and part of the old memory. Note that it is part of the old age but not all of the old age. G1 tracks the garbage collection value in each Region, giving priority to the region with the highest value within the garbage collection time specified by the user

Full GC: if the object memory allocation speed is too fast and the mixed GC has not been reclaimed, resulting in the old age being filled, the full gc algorithm of full gc,G1 will be triggered, which is the serial old gc executed by single thread. This process is similar to CMS, which will lead to an unusually long pause time and avoid full gc as much as possible.

At this point, the study of "what are the garbage collectors that the interviewer often asks" is over. I hope I can solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.