JVM garbage collection mechanism and GC Performance Tuning

1. GC Overview:

Knowledge about JVM heap
Why is JVM heap first?
The JVM heap is the active space of Java objects. The class objects in the program are allocated with space, which stores all objects used by running applications. These objects are created in a new type of operation. When the object is useless, GC is used to take charge of this useless object (everyone on Earth knows ).
JVM heap
(1) New Domain: stores all newly generated objects
(2) old domain: objects in the new domain are moved into the old domain after a certain number of GC cycles
(3) Permanent domain: Storage Class and method object. From the configuration perspective, this domain is independent and not included in the JVM heap. The default value is 4 MB.

The new domain is divided into three parts: 1. The first part is called Eden. (Eden ?? Probably because Adam and Eve were the earliest targets of human activity ?) 2. The other two parts are called the secondary living space (kindergarten). Here I call one a space (from sqace) and the other B space (to space ).

GC:
GCWork


The purpose is clear: Find useless objects in the heap and reclaim the space occupied by these objects so that they can be reused.
MajorityGarbage Collection


The algorithm idea is the same: make all the objects into a set, or you can think of it as a tree structure, starting from the root of the tree, as long as you can find all the active objects, if not, this object is the withered yellow flower yesterday and should be recycled.

In Sun's documentation, the new JVM heap domain adopts the coping algorithm.
,
This algorithm is proposed to overcome the handle overhead and solve the garbage collection of heap fragments. At the beginning, it divides the heap into one object plane and multiple idle planes. The program allocates space for the object from the object plane. When the object is full
The garbage collection of the coping algorithm scans active objects from the root set and copies each active object to the idle surface (so that there is no idle hole between the memory occupied by the active object ), in this way, the idle surface becomes an object surface,
The original object plane becomes idle, and the program allocates memory in the new object plane.

All newly generated objects are stored in Eden. When Eden is full (there are too many children), GC starts to work. First, stop the application and start to collect garbage, copy all the objects that can be found to space A. Once space a is full, GC copies all the objects that can be found in space a to Space B (overwrite the original storage objects). When Space B is full, GC copies all the objects that can be found in Space B to space A. In this process, AB swaps roles. The Guest officer said: Copy and copy the files, so don't bother? When is the header? Don't worry. after a certain number of GC operations on the activity object, these activity objects will be placed in the old domain. For these activities, kindergarten in the new domainLifeIt's over.
Why is the new domain so hard?
At first, I was confused about this and checked some information. It turned out that most of the objects generated by the application are short-lived. The ideal state of the copying algorithm is, all objects removed from Eden will be collected because these are short-lived objects and should be collected after a certain number of GC operations. Therefore, the objects moved into the old domain will be long-lived, this prevents the application from being affected by the back-and-forth replication of the AB space.
In fact, this kind of ideal state is very difficult to achieve, and there are inevitably long-lived objects in the application. The inventor of the copying algorithm wants these objects to be put in the new domain as much as possible to ensure small-scale replication, the overhead of compressing the old domain is much larger than copying in the new domain (the old domain is described below ).

The old domain uses a tracing algorithm called Mark-clear-compression collector. Note that there is a compression, which is a very costly operation.

Garbage collection is mainly used to recycle young generation blocks and old generation block memory. YG is used to store newly generated objects. After several collections, the uncollected objects are moved to og, garbage collection for YG is also called minorgc. For og garbage collection, it is also called majorgc. The two memory collections do not interfere with each other.

Ii. GC Process
:
[Older generation] [kernel vor 1] [kernel vor 2] [Eden] * Young Generation = Eden + kernel vor1. when Eden is full, young GC is triggered; 2. young GC does two things: 1. Remove some useless objects; 2.
, And send the old referenced object to the example or. After several GC operations, the example VOR is placed in the old object. 3. When old is full, full GC is triggered. Full GC consumes a lot of memory, and most of the garbage in Old and young is recycled. At this time, user threads will be blocked. 3. A larger proportion of young generation is not necessarily the best.
Setting the size of young to half the size of the total heap results in inefficiency. If it is set too small, it will cause a bottleneck because the young generation collection program has to run frequently. Iv. Summary
From the above derivation, we can draw many conclusions. The following is a summary of the experiences of the predecessors and their own understandings.
1. The JVM heap size determines the GC running time. If the JVM heap size exceeds a certain limit, GC runs for a long time.
2. The longer the object will survive, the longer the GC needs to be recycled, which affects the collection speed.
3. Most objects are short-lived. Therefore, if these objects can survive a GC running cycle, wonderful!
4. In applications, the speed at which objects are created and released determines the garbage collection frequency.
5. If a GC running cycle exceeds 3-5 seconds, the running of the application will be greatly affected. If yes, the JVM heap size should be reduced.
6. Previous experiences: Generally, the JVM heap size should be 80% of the physical memory. 5. view the case:

Jmap-heap 2343
Attaching to process ID 2343, please wait...
Debugger Attached successfully.
Server compiler detected.
JVM version is 11.0-

Using thread-local object allocation.

Parallel GC with 8 thread (s)

Heap Configuration:
Minheapfreeratio = 40
Maxheapfreeratio = 70
Maxheapsize = 4294967296 (4096.0 MB)
Newsize = 2686976 (2.5625 MB)
Maxnewsize =-65536 (-0.0625 MB)
Oldsize = 5439488 (5.1875 MB)
Newratio = 2 (YG, OG size ratio)

Required vorratio = 8
Permsize = 21757952 (20.75 MB)
Maxpermsize = 268435456 (256.0 MB)

Heap usage:
PS young generation
Eden space:

Capacity = 1260060672 (1201.6875 MB)

Used = 64868288 (61.86322021484375 MB)

Free = 1195192384 (1139.8242797851562 MB)

5.148028935546367% used

From space:

Capacity = 85524480 (81.5625 MB)

Used = 59457648 (56.70323181152344 MB)

Free = 26066832 (24.859268188476562 MB)

69.52120375359195% used

To space:

Capacity = 85852160 (81.875 MB)

Used = 0 (0.0 MB)

Free = 85852160 (81.875 MB)

0.0% used

~~~~~~~~~~~~~~~~~~~~~~~~~~ The three parts are the YG size and usage described above.
PS old generation
Capacity = 2291138560 (2185.0 MB)
Used = 1747845928 (1666.8757705688477 MB)
Free = 543292632 (518.1242294311523 MB)
76.28722062099989% used
~~~~~~~~~~~~~~~~~~~~~~~~~~ OG size and usage
PS perm generation
Capacity = 108265472 (103.25 MB)
Used = 107650712 (102.6637191772461 MB)
Free = 614760 (0.5862808227539062 MB)
99.43217353728436% used

YG Memory 1g, OG memory 2g, total memory 4G
In this configuration, the GC running condition is as follows:
Jstat-gcutil-H5 2343 4S 100
S0 S1 e o p ygc ygct FGC fgct GCT
79.82 0.00 75.34 78.55 99.44 7646 1221.668 398 2052.993 3274.661
0.00 79.52 0.62 78.63 99.44 7647 1221.782 398 2052.993 3274.775 a yg gc occurs here, that is, minorgc, takes 0.12 s

0.00 79.52 28.95 78.63 99.44 7647 1221.782 398 2052.993 3274.775
0.00 79.52 46.34 78.63 99.44 7647 1221.782 398 2052.993 3274.775

At the same time, we can see that a total of 398 major GC operations took 2052.993 of the total time, so the GC time of each major is: 2052.993/398 = 5.16 seconds.

This is a very serious problem. During the major GC process, the program will be suspended and the response will fail. It will be suspended for more than 5 seconds. This is unacceptable to anyone.

Similarly, minor GC is performed 7647 times, and the average time of 1221.782 times is 0.16 seconds, which is acceptable.

Let's take a look at the modified Configuration:

Jmap-heap 14103
Attaching to process ID 14103, please wait...
Debugger Attached successfully.
Server compiler detected.
JVM version is 11.0-

Using Parallel threads in the new generation.

Using thread-local object allocation.

Concurrent mark-sweep GC

Heap Configuration:
Minheapfreeratio = 40
Maxheapfreeratio = 70
Maxheapsize = 4294967296 (4096.0 MB)
Newsize = 536870912 (512.0 MB)
Maxnewsize = 536870912 (512.0 MB)
Oldsize = 5439488 (5.1875 MB)
Newratio = 4
YG: og
Required vorratio = 8
Permsize = 268435456 (256.0 MB)
Maxpermsize = 268435456 (256.0 MB)

Heap usage:
New Generation (EDEN + 1 kernel vor space ):

Capacity = 483196928 (460.8125 MB)

Used = 428284392 (408.4438247680664 MB)

Free = 54912536 (52.368675231933594 MB)

88.63557841162434% used

Eden space:

Capacity = 429522944 (409.625 MB)

Used = 404788608 (386.0364990234375 MB)

Free = 24734336 (23.5885009765625 MB)

94.24144010337199% used

From space:

Capacity = 53673984 (51.1875 MB)

Used = 23495784 (22.407325744628906 MB)

Free = 30178200 (28.780174255371094 MB)

43.77499534970238% used

To space:

Capacity = 53673984 (51.1875 MB)

Used = 0 (0.0 MB)

Free = 53673984 (51.1875 MB)

0.0% used

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ YG size and Usage Status
Concurrent mark-sweep generation:
Capacity = 3758096384 (3584.0 MB)
Used = 1680041600 (1602.2125244140625 MB)
Free = 2078054784 (1981.7874755859375 MB)
44.70459052494594% used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ OG size and Usage Status
Perm generation:
Capacity = 268435456 (256.0 MB)
Used = 128012184 (122.0819320678711 MB)
Free = 140423272 (133.9180679321289 MB)
47.688254714012146% used

In this configuration, GC running condition:
Jstat-gcutil-H5 14103 4S 100
S0 S1 e o p ygc ygct FGC fgct GCT
47.49 0.00 64.82 46.08 47.69 20822 2058.631 22.734 2081.365
0.00 37.91 38.57 46.13 47.69 20823 68 2058.691 22.734 here a yg gc, that is, minorgc, took 2081.425 s

46.69 0.00 15.19 46.18 47.69 20824 2058.776 22.734 2081.510
46.69 0.00 74.59 46.18 47.69 20824 2058.776 22.734 2081.510
0.00 40.29 19.95 46.24 47.69 20825 2058.848 22.734 2081.582

Average majorgc time: 22.734/68 = 0.334 seconds (above is more than 5 seconds)

Minorgc Average Time: 2058.691/20823 = 0.099 seconds (slightly less than above)