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

This article introduces how to use the G1 recycler in java, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

G1 recycler

The G1 collector is a new garbage collector officially used in jdk1.7 and is the default collector for jdk9 and later versions. From a generational point of view, G1 is still a generational garbage collector, it can distinguish between the young and the old, there are still eden and survivor areas, but from the structure of the heap, it does not require the whole eden area, the young generation or the old age to be continuous. G1 uses a new partitioning algorithm with the following features:

Parallelism: during the recovery period, G1 can be operated by multiple GC threads at the same time, making effective use of multi-core computing power.

Concurrency: G1 has the ability to execute alternately with the application, part of the work can be performed at the same time as the application, and generally speaking, the application is not completely blocked during the entire recycling period.

Generational GC:G1 is still a generational recycler, but unlike previous collectors, it takes care of both the younger generation and the older generation, while other recyclers work either in the younger generation or in the old age.

Spatial collation: G1 will move objects appropriately during recycling, unlike CMS, which simply marks cleaned objects. After several GC, CMS must be defragmented. Unlike G1, each time it is recycled, it will effectively copy objects and reduce debris space.

Predictability: due to partition reasons, G1 can select only part of the area for memory recovery, which reduces the scope of recycling, and the global pause can be better controlled.

1G1memory partition and main collection process

G1 divides the heap into regions, and only a few of them are reclaimed each time, so as to control the pause time caused by garbage collection.

The recovery process of G1 may have four stages:

New generation GC

Concurrent marking cycle

Mixed recovery

FullGC may be done if necessary

2. The new generation GC of G1

The main work of the new generation GC is to recover eden area and survivor area. Once the eden area is occupied, the new generation of GC will be started. The new generation GC only deals with eden area and survivor area. After recycling, all eden areas should be emptied, while survivor areas will be reclaimed part of the data.

3. Concurrent marking cycle of G1

The concurrency phase of G1 is a bit similar to that of CMS, in order to reduce the pause time and extract and execute separately the parts that can be concurrently with the application.

The concurrent marking cycle can be divided into the following steps:

Initial tag: marks objects that are directly reachable from the root node. This phase is accompanied by a new generation of GC, which produces a global pause at which the application thread must stop execution.

Root zone scan: since the initial tag is bound to be accompanied by a new generation of GC, after initializing the tag, the eden area is cleared and the surviving object is moved into the survivor area. At this stage, older areas directly reachable from the survivor area are scanned and these directly reachable objects are marked. This process can be performed concurrently with the application, but the root zone scan cannot be performed at the same time as the new generation GC, because if you happen to need a new generation GC at this time, you need to wait for the root zone scan to finish. If this happens, the time of this new generation of GC will be extended.

Concurrent tags: similar to CMS, concurrent tags will scan and find surviving objects throughout the heap and mark them. This is a concurrent process, and it can be interrupted by a new generation of GC.

Relabeling: like CMS, relabeling results in application pause. Since the application is still running during the concurrent tagging process, the tagging results may need to be corrected, so the previous tagging results are supplemented here. In G1, this process is done using the SATB (Snapshot-At-The-Beginning) algorithm, which means that G1 creates a snapshot of the living object at the beginning of the tag, which helps speed up the relabeling.

Exclusive cleanup: this phase can cause a pause. It calculates the proportion of surviving objects and GC recycling in each region, and sorts it to identify areas that can be mixed for recycling. Identify areas that can be mixed and recycled. At this stage, the memory set (Remebered Set) is also updated. In this stage, the areas that need to be mixed and recycled are given and marked, and this information is needed in the mixed recycling phase.

Concurrency cleanup: completely idle areas are identified and cleaned up here. It is a concurrent cleanup and does not cause a pause.

In addition to initial tagging, relabeling, and exclusive cleanup, several other phases can be performed concurrently with the application.

During the concurrent marking cycle, G1 generates the following logs:

3.1initial marker, which is accompanied by a Cenozoic GC [GC pause (G1 Humongous Allocation) (young) (initial-mark), 0.0014636 secs]. [Eden: 2048.0K (14.0m)-> 0.0B (13.0m) Survivors: 0.0B-> 1024.0K Heap: 13.8m (40.0m)-> 2624.1K (40.0m)] [Times: user=0.01 sys=0.00, real=0.00 secs] 3.2 one concurrent root zone scan, which can not be interrupted by Cenozoic GC. [GC concurrent-root-region-scan-start] [GC concurrent-root-region-scan-end, 0.0003832 secs] 3.3.concurrent tags can be interrupted by Cenozoic GC. The following log shows that one concurrent tag is interrupted by Cenozoic GC for 3 times. [GC concurrent-mark-start] [GC pause (young), 0.0003382 secs]... [Eden: 2048.0K (14.0m)-> 0.0B (13.0m) Survivors: 0.0B-> 1024.0K Heap: 13.8m (40.0m)-> 2624.1K (40.0m)] [Times: user=0.01 sys=0.00, real=0.00 secs]. [Eden: 2048.0K (14.0m)-> 0.0B (13.0m) Survivors: 0.0B-> 1024.0K Heap: 13.8m (40.0m)-> 2624.1K (40.0m)] [Times: user=0.01 sys=0.00, real=0.00 secs]. [Eden: 2048.0K (14.0m)-> 0.0B (13.0m) Survivors: 0.0B-> 1024.0K Heap: 13.8m (40.0m)-> 2624.1K (40.0m)] [Times: user=0.01 sys=0.00, real=0.00 secs] [GC concurrent-mark-end, 0.0003929 secs] 3.4 remark: it will cause a global pause Its log is as follows: [GC remark [Finalize Marking, 0.0006027 secs] [GC ref-proc, 0.0000295 secs] [Unloading, 0.0003390 secs], 0.0010737 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 3.5 after being re-marked, exclusive cleaning will be carried out, and the survival objects in each area will be recalculated, thus the effect of GC in each region can be obtained. Its log is as follows: [GC cleanup 10m-> 10m (40m), 0.0003016 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 3.6.concurrent cleanup is performed concurrently. It calculates the number of surviving objects in each region according to the exclusive cleaning phase, and directly reclaims the areas that do not contain living objects. Its log is as follows: [GC concurrent-cleanup-start] [GC concurrent-cleanup-end, 0.0000016 secs] 4. Mixed recovery

In the concurrent marking cycle, although some objects are recycled, generally speaking, the proportion of recycling is quite low. However, after the concurrent marking cycle, G1 already knows which areas contain more garbage objects, and these areas can be recycled specifically in the mixed recycling phase. This stage is called mixed recycling because it not only performs the normal young generation GC, but also selects some marked old age areas for recycling, which deals with both the new generation and the old age.

Mixing GC results in the following logs:

[GC pause (mixed), 0.0003382 secs]... [Eden: 2048.0K (14.0m)-> 0.0B (13.0m) Survivors: 0.0B-> 1024.0K Heap: 13.8m (40.0m)-> 2624.1K (40.0m)] [Times: user=0.01 sys=0.00, real=0.00 secs]

The hybrid GC executes multiple times until enough memory space is reclaimed, and then it triggers a new generation of GC. After the new generation of GC, it is difficult to deal with the concurrent marking cycle again, and finally it will cause the execution of mixed GC.

5. Full GC if necessary

Similar to CMS, concurrent recycling cannot completely avoid insufficient memory during the recycling process in particularly busy situations by letting the application and GC threads work alternately. When this happens, G1 will also be transferred to a FullGC.

When G1 is marked concurrently, because the old age is quickly populated, G1 terminates the concurrent tag and goes to a Full GC:

[GC concurrent-mark-start] [Full GC 898-> 896 (900m), 0.7003382 secs] [Eden: 0K (45.0M)-> 0.0B (45.0M) Survivors: 0.0B-> 0B Heap: 898.7m (900.0m)-> 896.2m (900.0m)] [Times: user=1.01 sys=0.00, real=0.075 secs] [GC concurrent-mark-abort]

In addition, if there is not enough space when mixing GC, or if the survivor area and the old age are unable to accommodate the surviving objects in the new generation GC, it will lead to a FullGC.

6. The log # of G1 indicates that a new generation of GC occurred in the application, which took 0.0018193 seconds during the initial marking, which means that the program paused for at least 0.0018193 seconds [GC pause (G1 Humongous Allocation) (young) (initial-mark), 0.0018193 secs] # subsequent parallel time, indicating the total time spent by all GC threads, which is 0.9ms here. A workers of 8 indicates the execution of 8 GC threads [Parallel Time: 0.9 ms, GC Workers: 8] # GC threads. Here, statistics are given for 8 threads, such as average, minimum, maximum and difference (the difference between the maximum and minimum values), and # 106.6 means 106.6 milliseconds after the application starts. Started the GC thread [GC Worker Start (ms): Min: 106.6, Avg: 106.7, Max: 106.7, Diff: 0.1] # Statistical value of root scan time [Ext Root Scanning (ms): Min: 106.6, Avg: 0.4, Max: 0.5, Diff: 0.1, Sum: 3.3] # time taken to update the memory set (Remember Set). # memory set is a data structure maintained in G1, referred to as RS. Each G1 region has a RS associated with it. Because G1 is recycled according to area #, for example, when recovering objects in area A, objects in area B are probably not recycled, in order to recover objects in area A, scan area B and even the entire heap to determine which objects in area An are unreachable, which is obviously costly. Therefore, G1 records the objects referenced by other regions in area # An in the RS of area A, so that when reclaiming area A, the RS can be regarded as part of the root set of area A, thus avoiding scanning the entire heap #. Because the reference relationships between objects can change from time to time while the system is running, in order to track these reference relationships more efficiently, # records these changes in Update Buffers. The Processed Buffers here refers to processing this Update Buffers data. [Update RS (ms): Min: 0, Avg: 0, Max: 0, Diff: 0, Sum: 0] [Processed Buffers: Min: 0, Avg: 0, Max: 0, Diff: 0, Sum: 0] # time to scan RS [Scan RS (ms): Min: 0, Avg: 0, Max: 0, Diff: 0 Sum: 0] [Code Root Scanning (ms): Min: 0, Avg: 0, Max: 0, Diff: 0, Sum: 0] # before official recycling G1 evacuates the objects in the recycled area and places the surviving objects in other areas, so object replication is required [Object Copy (ms): Min: 0.2, Avg: 0.3, Max: 0.4, Diff: 0.2, Sum: 2.2] # gives the GC project thread termination information, where the termination time is the time spent by the thread in the termination phase. Before the GC thread terminates, they check the work queue of its # other GC thread to see if there are still any object references that have not been processed, and if other threads still have unfinished data, the thread requesting # termination will help it finish as soon as possible and then try to terminate. Where Termination Attempts shows the number of terminations of the worker thread. [Termination (ms): Min: 0, Avg: 0, Max: 0. 2, Diff: 0. 2, Sum: 1] [Termination Attempts: Min: 1, Avg: 2. 9, Max: 6, Diff: 5, Sum: 23] # shows the time spent by GC threads on other tasks [GC Worker Other (ms): Min: 0, Avg: 0, Max: 0, Diff: 0 Sum: 0.1] [GC Worker Total (ms): Min: 0.8, Avg: 0.8, Max: 0.9, Diff: 0.1, Sum: 6.6] # the completion time of the GC worker thread [GC Worker End (ms): Min: 107.5, Avg: 107.5, Max: 107.5 Diff: 0.0] [Code Root Fixup: 0.0 ms] [Code Root Purge: 0.0 ms] # shows the time when the CardTable was emptied RS relies on CardTable to record which objects are alive. [Clear CT: 0.1 ms] # shows the time spent on several other tasks, such as selecting CSet (Collection Sets) Represents the selected collection of regions to be recycled), Ref Proc (time to process weak references, soft references), Ref End (weak references, soft references queuing time) and Free CSet (time to release areas in CSet that have been recycled by #) Including their RS) [Other: 0.8 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.7 ms] [Ref Enq: 0.0 ms] [Redirty Cards: 0.1 ms] [Humongous Register: 0.0 ms] [Humongous Reclaim: 0.0 ms] [Free CSet: 0.0 ms] [Eden: 2048.0K (14.0m)-> 0.0B (13) .0m) Survivors: 0.0B-> 1024.0K Heap: 13.8m (40.0m)-> 2656.1K (40.0m)] [Times: user=0.00 sys=0.00 Real=0.00 secs] 7. Related parameters

-XX:+UseG1GC: enable the G1 recycler

-XX:MaxGCPauseMillis: used to specify the maximum pause time of the target. If any pause time exceeds this setting, G1 will try to adjust the ratio of the new generation to the old, adjust the heap size, adjust the promotion age, etc., in an attempt to achieve the set goal. For performance tuning, you can always have both fish and bear's paw, and if the pause time is shortened, for the new generation, it is likely to increase the number of new generation GC. For the old days, in order to get a short pause, when mixing GC, the number of areas collected at a time will also be reduced, which undoubtedly increases the possibility of FullGC.

-XX:ParallelGCThreads: sets the number of worker threads for GC during parallel recycling.

-XX:InitatingHeapOccupancyPercent: specifies that when the utilization of the whole heap reaches, the execution of the concurrent marking cycle is triggered. The default value is 45.InitatingHeapOccupancyPercent, which, once set, will never be modified by G1, which means that G1 will not try to change this value to meet the goal of MaxGCPauseMillis, so the possibility of causing FullGC is greatly increased. On the contrary, a too small InitatingHeapOccupy percentage value will make the execution of concurrent marking cycle very frequent, and a large number of GC threads preempt CPU. Results in a decline in the performance of the application.

About how to use the G1 recycler in java to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.