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

In this issue, the editor will bring you about the principle of GC in Java. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

1 GC tuning goal

In most cases, GC tuning of Java programs focuses on two goals: response speed and throughput

Response speed (Responsiveness) response speed refers to how quickly a program or system responds to a request. For example, the response time of user order query, for systems with high response speed, a large pause time is unacceptable. The focus of tuning is to respond quickly in a short time.

Throughput (Throughput) Throughput is concerned with the maximum workload of the application system within a specific period of time, such as the number of tasks that the batch processing system can complete per hour, and for systems optimized in terms of throughput, a longer GC pause time is also acceptable, because high-throughput applications are more concerned with how to complete the whole task as quickly as possible, regardless of rapid response to user requests.

In GC tuning, the application pause time caused by GC affects the system response speed, and the CPU utilization of GC processing threads affects the system throughput.

2 GC generation collection algorithm

Modern garbage collectors basically adopt generation-by-generation collection algorithm, and its main idea is to logically divide the heap memory of Java into two pieces: the new generation and the old age, and adopt different garbage collection strategies for objects of different survival periods and sizes.

New generation (Young Generation)

The new generation is also called the younger generation, most objects are created in the new generation, and the life cycle of many objects is very short. Only a small number of objects survive after each new generation of garbage collection (also known as Young GC, Minor GC, YGC), so using the replication algorithm, the collection can be completed with only a small amount of replication operation cost.

The Cenozoic is divided into three regions: one Eden region and two Survivor regions (S0, S1, also known as From Survivor and To Survivor). Most of the objects are generated in the Eden region. When the Eden area is full, the surviving objects are copied to two Survivor zones (one of them). When this Survivor area is full, objects that survive in this area and do not meet the criteria for promotion to the old age will be copied to another Survivor area. Each time the object experiences a copy, the age is added by 1, and after reaching the promotion age threshold, the object is transferred to the old age.

Old age (Old Generation)

Objects that are still alive after N times of garbage collection in the new generation will be put into the old era, and the survival rate of objects in this area is high. The "mark-collation" algorithm is usually used in garbage collection in the old days.

3 GC event classification

According to the different areas of garbage collection, garbage collection is usually divided into Young GC, Old GC, Full GC and Mixed GC.

(1) Young GC

The garbage collection event of Cenozoic memory is called Young GC (also known as Minor GC). Young GC is always triggered when JVM cannot allocate new objects to Cenozoic memory space, such as when the Eden area is full. The higher the frequency of new object allocation, the higher the frequency of Young GC

Young GC causes Stop-The-World every time, suspending all application threads, and the pause time is almost negligible compared with the pause caused by the old GC.

(2) Old GC, Full GC, Mixed GC

Old GC, only clean up the GC events in the old space, only the concurrent collection of CMS is this mode Full GC, clean up the GC events of the whole heap, including Cenozoic, old age, metaspace, etc.

Mixed GC, cleaning up the whole new generation and part of the old GC, only G1 has this model.

4 GC log analysis

GC log is a very important tool, which accurately records the execution time and result of each GC. By analyzing the GC log, you can tune the heap and GC settings, or improve the object allocation mode of the application. The enabled JVM startup parameters are as follows:

-verbose:gc-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps

Common Young GC and Full GC logs are as follows:

The free GC log graphic analysis tool recommends the following two:

GCViewer, download the jar package and run it directly

Gceasy,web tool for uploading GC logs for online use

5 memory allocation strategy

The automatic memory management provided by Java can be summed up as solving the problem of memory allocation and recycling of objects. Memory recovery has been introduced earlier. Here are some of the most common memory allocation strategies.

Object priority allocation in Eden area in most cases, objects are allocated in the pre-Cenozoic Eden area. When there is not enough space in the Eden zone to allocate, the virtual machine will initiate a Young GC

In the old age between large objects, JVM provides an object size threshold parameter (- XX:PretenureSizeThreshold, the default value is 0, which means that no matter how much memory is allocated first in Eden), objects larger than the threshold value set by the parameter are allocated directly in the old age, so that large memory replication of objects in Eden and two Survivor can be avoided.

Objects that survive for a long time will enter the old age. Every time an object goes through garbage collection and is not recycled, its age will be increased by 1. Objects that are larger than the age threshold parameter (- XX:MaxTenuringThreshold, default 15) will be promoted to the old age.

Space allocation guarantee before Young GC, JVM needs to estimate whether the old age can accommodate the surviving objects promoted from the new generation of Young GC to the old age, in order to determine whether it is necessary to trigger GC to reclaim the old space in advance, which is calculated based on the space allocation guarantee policy:

ContinueSize: the largest available continuous space in the old days

If the Young GC is successful (the promotion object after Young GC can be put into the old age), it means that the guarantee is successful and there is no need for Full GC to improve performance. If it fails, there will be a "promotion failed" error, which means that the guarantee fails, and Full GC is required.

Dynamic age determination the age of the new generation object may be promoted before reaching the threshold (specified by the MaxTenuringThreshold parameter). If, after Young GC, the sum of all the objects of the same age is greater than half of any Survivor space (S0 or S1 total space), S0 or S1 will not be able to accommodate the surviving new generation object, and the object whose age is greater than or equal to this age can directly enter the old age. You don't have to wait until the age required in MaxTenuringThreshold

In addition, if the S0 or S1 area after Young GC is not enough to accommodate: the surviving objects of the new generation who do not meet the conditions for promotion to the old age will cause these surviving objects to enter the old age directly, which should be avoided as far as possible.

CMS principle and the explanation of tuning 1 noun

Reachability analysis algorithm: used to judge whether an object is alive or not, the basic idea is to use a series of objects called "GC Root" as the starting point (common GC Root has system class loaders, objects in the stack, active threads, etc.), based on the object reference relationship, search down from GC Roots, and the path is called reference chain. When an object is not connected to GC Root with any reference chain, it is proved that the object is no longer alive.

The object reference relationship is analyzed in the process of Stop The World:GC. In order to ensure the accuracy of the analysis results, it is necessary to pause all Java execution threads to ensure that the reference relationship does not change dynamically. This pause event is called Stop The World (STW).

Safepoint: some special locations during code execution, when the thread executes to these locations, indicating that the current state of the virtual machine is safe, where the thread can be paused if GC is needed. HotSpot uses active interruptions to allow the execution thread to poll at run time for signs that need to be paused, and to suspend interruptions if necessary.

2 introduction to CMS

CMS (Concurrent Mark and Swee concurrency-tag-cleanup) is a garbage collection algorithm based on concurrency and tag removal algorithm, which is only used for garbage collection in old times. When the CMS collector works, let the GC thread and the user thread execute concurrently as far as possible, in order to reduce the STW time.

Enable the CMS garbage collector with the following command line arguments:

-XX:+UseConcMarkSweepGC

It is worth adding that the CMS GC introduced below refers to the old GC, while Full GC refers to the whole heap GC events, including Cenozoic, old age, metaspace, etc., there is a distinction between the two.

3Cenozoic garbage collection

The new generation of garbage collectors that can be used with CMS are the Serial collector and the ParNew collector. Both collectors use the tag copy algorithm, which triggers the STW event and stops all application threads. The difference is that Serial is single-threaded and ParNew is multithreaded.

4 garbage collection in the old years

In order to obtain the minimum pause time and minimize the STW time, CMS GC can be divided into seven stages.

Phase 1: initial marking (Initial Mark)

The goal of this phase is to mark all living objects in the old era, including direct references to GC Root, as well as objects referenced by surviving objects in the new generation, triggering the first STW event.

This process supports multithreading (single thread before JDK7, parallel after JDK8, which can be adjusted by parameter CMSParallelInitialMarkEnabled)

Phase 2: concurrent marking (Concurrent Mark)

At this stage, GC threads and application threads execute concurrently, traversing the surviving objects initially marked in stage 1, and then continue to recursively mark the objects that these objects can reach.

Phase 3: concurrent pre-cleanup (Concurrent Preclean)

GC threads and application threads are also executed concurrently at this stage, because phase 2 is executed concurrently with application threads, and some reference relationships may have changed. Through card marking (Card Marking), the old space logic is divided into equal size areas (Card) in advance. If the reference relationship changes, JVM will mark the changed area "dirty area" (Dirty Card), and then at this stage, these dirty areas will be found, refresh the citation relationship, and clear the "dirty area" mark.

Phase 4: concurrent cancelable pre-cleanup (Concurrent Abortable Preclean)

The application thread is not stopped at this stage. In this stage, we try to do as much work as possible before the final marking phase (Final Remark) of STW, so as to reduce the application pause time to be processed continuously during this stage: marking the reachable objects of the old age, scanning and processing the objects in the Dirty Card area, the termination conditions of the loop are as follows: (1) the number of cycles reaches the threshold of the cycle execution time (3) the memory utilization of the new generation reaches the threshold.

Phase 5: final marking (Final Remark)

This is the second (and last) STW phase of the GC event, and the goal is to complete the marking of all living objects in the old age. Execute at this stage: 1 iterate through the new generation of objects, re-mark 2 according to GC Roots, re-mark 3 times the old Dirty Card, re-mark

Phase 6: concurrent cleanup (Concurrent Sweep)

This phase is executed concurrently with the application without STW pause, and garbage objects are cleared according to the result of the markup.

Phase 7: concurrent reset (Concurrent Reset)

This phase executes concurrently with the application and resets the internal data related to the CMS algorithm in preparation for the next GC loop

5 CMS FAQ final marking phase pause time is too long

About 80% of the GC pause time of CMS is in the final marking stage (Final Remark). If the pause time of this stage is too long, the common reason is the invalid reference of the new generation to the old age. In the previous stage of concurrent cancelable pre-cleaning, the cycle is not completed within the threshold time, and it is too late to trigger Young GC to clean up these invalid references.

By adding the parameter:-XX:+CMSScavengeBeforeRemark. Trigger Young GC before performing the final operation, thereby reducing the invalid references of the new generation to the old age and reducing the pause in the final marking phase, but if Young GC has been triggered in the previous stage (concurrent cancelable pre-cleaning), Young GC will also be triggered repeatedly

Concurrency Mode failure (concurrent mode failure) & Promotion failure (promotion failed) problem

Concurrency mode failure: when CMS performs collection, garbage collection occurs in the new generation, and in the old days there is not enough space for promoted objects, CMS garbage collection will degenerate into a single-threaded Full GC. All application threads are suspended, and all invalid objects in the old days are reclaimed.

Promotion failure: when garbage collection occurs in the new generation, there is enough space in the old era to accommodate the promoted object, but the promotion fails due to the fragmentation of free space, which triggers a single-threaded Full GC with compression action.

Failure of concurrent mode and failure of promotion can lead to a long pause. Common solutions are as follows:

Lower the threshold for triggering CMS GC, that is, the value of the parameter-XX:CMSInitiatingOccupancyFraction, and let CMS GC execute as soon as possible to ensure that there is enough space.

Increase the number of CMS threads, that is, parameter-XX:ConcGCThreads

Increase the space of the old age

Let the object be recycled in the new generation as far as possible to avoid entering the old age.

Memory fragmentation problem

Usually, the GC process of CMS is based on the tag removal algorithm without compression action, resulting in more and more memory fragments that need to be compressed. It is common to trigger memory fragmentation compression in the following scenarios:

Failure of promotion guarantee in the new generation of Young GC (promotion failed)

The program initiatively executes System.gc ()

You can set the number of times FullGC triggers a compression through the value of parameter CMSFullGCsBeforeCompaction. The default value is 0, which means compression will be triggered every time you enter FullGC. The algorithm with compression action is the single-threaded Serial Old algorithm mentioned above, and the STW time is very long, so you need to reduce the compression time as much as possible.

A brief introduction to the principle and tuning of G1

G1 (Garbage-First) is a server-oriented garbage collector that supports garbage collection in new and old space, mainly for machines with multi-core processors and large memory. The main design goal of G1 is to achieve predictable and configurable STW pause times.

2 G 1 heap space partition

Region

In order to realize the recovery of large memory space and low pause time, it is divided into several Region of equal size. Each small stack may be Eden, Survivor or Old, but it can only belong to a generation at the same time.

Logically, all the Eden and Survivor regions together are the new generation, and all the Old regions are the old age, and the memory Region regions of the new generation and the old age are automatically controlled by G1 and are constantly changing.

Giant object

When the size of an object is more than half of that of Region, it is considered to be a giant object (Humongous Object), which is directly assigned to the giant object area (Humongous regions) of the old era. These giant regions are a continuous set of regions. There is at most one giant object in each Region, and giant objects can occupy multiple Region.

The significance of G1 dividing heap memory into Region is as follows:

Each GC does not have to deal with the entire heap space, but only a part of the Region at a time to achieve a large amount of memory GC

By calculating the recycling value of each Region, including the recycling time and recyclable space, we can collect as many garbage objects as possible in a limited time, and control the pause time caused by garbage collection within the expected configured time range. This is also the origin of the G1 name: garbage-first.

3G1 working mode

For the new generation and the old age, G1 provides two GC modes, Young GC and Mixed GC, which will lead to Stop The World

Young GC when the space of the new generation is insufficient, the G1 triggers the Young GC to reclaim the new generation space Young GC mainly to GC the Eden area, which is triggered when the Eden space is exhausted. Based on the idea of generation recovery and replication algorithm, each Young GC selects all the new generation Region, calculates the space of the Eden area and Survivor area needed for the next Young GC, and dynamically adjusts the number of Region occupied by the new generation to control the Young GC overhead.

Mixed GC when the old age space reaches the threshold, Mixed GC will be triggered, and all the Region in the Cenozoic generation will be selected. According to the statistics of the global concurrent marking phase (described below), several old Region with high collection revenue can be obtained. Within the scope of the cost target specified by the user, choose the old Region with high income for GC as far as possible, and control the Mixed GC overhead by choosing which old Region and how many Region.

4 Global concurrent marking

The main purpose of global concurrency marking is to find out the Region areas with higher recovery benefits for Mixed GC calculation, which is divided into five stages.

Phase 1: initial tagging (Initial Mark) pauses all application threads (STW) and simultaneously marks objects (native stack objects, global objects, JNI objects) that are directly reachable from GC Root. When the trigger condition is reached, G1 does not immediately initiate a concurrent marking cycle, but waits for the next Cenozoic collection to complete the initial marking using the STW period collected by the Cenozoic generation, which is called Piggybacking.

Phase 2: root zone scan (Root Region Scan) after the end of the initial marking pause, the new generation of objects collected and completed are copied to the Survivor, and the application thread becomes active; at this time, in order to ensure the correctness of the marking algorithm, all the objects newly copied to the Survivor partition need to find out which objects have references to the old objects and mark these objects as Root. This process is called root partition scanning (Root Region Scanning), and the scanned Suvivor partition is also known as root partition (Root Region); root partition scanning must be completed before the next Cenozoic garbage collection starts (subsequent concurrent markup may be interrupted by several Cenozoic garbage collection), because each GC produces a new collection of living objects.

Phase 3: the Concurrent Marking tag thread executes in parallel with the application thread to mark the surviving object information of the Region in each heap. This step may be interrupted by the new Young GC. All marking tasks must be scanned before the heap is full. If concurrent tagging takes a long time, it is possible that several new generation collections have been experienced during the concurrent marking process.

Phase 4: re-marking (Remark) and CMS are similar to pausing all application threads (STW) to complete the marking process to briefly stop the application thread, mark objects that have changed during the concurrent marking phase, and all living objects that have not been marked, while completing the calculation of survival data.

Phase 5: Cleanup prepares for the upcoming transition phase, which also performs all necessary tidying up calculations for the next tag:

Organize and update the respective RSet of each Region (remember set,HashMap structure, record which old objects point to references to objects in this Region,key that point to this Region, value is a specific Card area pointing to this Region, and RSet can be used to determine the survival information of objects in Region to avoid full heap scanning)

Recycle Region that does not contain living objects

Statistically calculate the collection of old-era partitions with high recovery returns (based on free space and pause targets)

5 G1 tuning attention point Full GC problem

There is no Full GC in the normal processing flow of G1, which occurs only when garbage collection cannot be handled (or triggered actively). The Full GC of G1 is the Serial old gc executed by a single thread, which results in very long STW, which is the focus of tuning. You need to avoid Full GC as far as possible. The common reasons are as follows:

The program initiatively executes System.gc ()

The old age space is filled during global concurrency marking (concurrency mode failed)

The old space was filled up during Mixed GC (promotion failed)

In Young GC, there is not enough space for living objects in the Survivor space and the old age.

Similar to CMS, common solutions are:

Increase the-XX:ConcGCThreads=n option to increase the number of concurrent markup threads, or the number of parallel threads during STW:-XX:ParallelGCThreads=n

Reduce-XX:InitiatingHeapOccupancyPercent pre-start marking cycle

Increase reserved memory-XX:G1ReservePercent=n. The default value is 10, which means that 10% of the heap memory is used as reserved memory. When the Survivor area does not have enough space to accommodate newly promoted objects, it will try to use reserved memory.

Giant object allocation

Each Region in the giant object area contains a giant object, and the remaining space is no longer used, resulting in space fragmentation. When G1 does not have the appropriate space to allocate giant objects, G1 will start serial Full GC to free space. You can increase the Region size by adding-XX:G1HeapRegionSize, so that a considerable number of giant objects are no longer giant objects, but are allocated in the ordinary way.

Do not set the size of the Young area

The reason is that in order to meet the target pause time as much as possible, the logical Young area will be adjusted dynamically. If the size is set, it will be overwritten and the control of pause time will be disabled

Average response time setting

Using the average response time of the application as a reference to set the MaxGCPauseMillis,JVM will try to meet this condition. It may be that 90% of the requests or more response times are within this, but it does not mean that all requests can be satisfied. Setting the average response time too low will lead to frequent GC.

Tuning methods and ideas

How to analyze the operation status of JVM GC and optimize it reasonably?

The core idea of GC optimization is to allow objects to be allocated and recycled in the new generation as much as possible, so as to prevent too many objects from entering the old age, resulting in frequent garbage collection in the old era, while giving the system enough memory to reduce the number of garbage collection in the new generation. System analysis and optimization is also carried out around this idea.

1 analyze the operation status of the system

Number of requests per second, how many objects are created per request, and how much memory is consumed by the system

Memory occupation in the old age, Full GC trigger frequency, Full GC trigger reason, long-time Full GC reason

Common tools are as follows:

Jstat jvm comes with command-line tools, which can be used to count memory allocation rate, GC times, GC time-consuming and common command formats.

Jstat-gc

The output return value represents the following:

For example: jstat-gc 32683 1000 10, count the progress of pid=32683, count once per second, count 10 times

Jmap jvm comes with command-line tools that can be used to understand the distribution of objects when the system is running. The common command formats are as follows

/ / the command line outputs the class name, the number of classes, the amount of memory occupied by the class, / / arranges the jmap-histo according to the memory occupied by the class in descending order, generates a snapshot of the heap memory dump, and exports the binary file of dump.hrpof under the current directory. / / you can use eclipse's MAT graphical tool to analyze jmap-dump:live,format=b,file=dump.hprof.

Jinfo command format

Jinfo

Used to view the extended parameters of a running Java application, including the Java System property and JVM command line arguments

Other GC tools

Jdk automatic real-time memory monitoring tool: VisualVM

GC log analysis: GCViewer, gceasy

GC parameter checking and optimization: http://xxfox.perfma.com/

2 GC optimization case

Data analysis platform system frequent Full GC

The platform mainly carries on the timing analysis statistics to the user behavior in the APP, and supports the report export, uses the CMS GC algorithm. In use, the data analyst found that the system page was often stuttered, and through the jstat command, it was found that about 10% of the living objects entered the old age after each Young GC of the system.

It turns out that because the space in the Survivor area is too small, the surviving objects cannot be placed in the Survivor area after each Young GC, and they enter the old age ahead of time. By enlarging the Survivor area, the Survivor area can accommodate the surviving objects after Young GC, and the objects enter the old age after many times of Young GC in the Survivor area. After adjustment, the frequency of the surviving objects entering the old age is only a few hundred Kb,Full GC when they run stably after each Young GC.

Service interfacing Gateway OOM

The gateway mainly consumes Kafka data, processes and calculates the data, and then forwards it to another Kafka queue. OOM appears in a few hours after the system is running, and a few hours after the system is rebooted, it is OOM again. The heap memory is exported through jmap, and the reason is found out only in the eclipse MAT tool analysis: the topic data of a business Kafka is asynchronously printed in the code. The amount of business data is large, and a large number of objects are accumulated in memory waiting to be printed, resulting in OOM.

Account rights management system Full GC frequently and for a long time

The system provides a variety of account authentication services, and when in use, it is found that the system services are often unavailable. Through the monitoring platform of Zabbix, it is found that the system frequently occurs Full GC for a long time, and the old heap memory is usually not full when triggered. It is found that System.gc () is called in the business code.

The above is what the principle of GC in Java is shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.