JVM (2) Understanding

The following content is excerpted from Baidu-zhi, mainly because I think it can be well understood, so I copied

Common GC algorithms:
1) Mark inactive objects
-- What is an inactive object? In general, it is a non-referenced object.

Tracking root object algorithm: This algorithm traces the root object in depth and marks all referenced root objects in heap. All unmarked objects are regarded as inactive objects and the occupied space is considered as inactive memory.

2) Clear inactive objects

Copy algorithm:
Method: divide the memory into two areas (from space and to space ). All objects are allocated to the from space. In the cleaning stage, copy all objects marked as active objects to space, and then identify the from space. Then, the IDs from sapce and to space are exchanged. The original from space becomes to sapce, and the original to space becomes from space. Repeat the above process for each cleanup.

Advantage: The copy algorithm ignores non-active objects. The number of copies depends only on the number of active objects. In addition, the heap space is organized during copy, that is, the space used to space is always continuous, and the memory usage efficiency is improved.

Disadvantage: divided from space and to space, the memory usage is 1/2.
Compaction Algorithm:
Method: During the cleaning of inactive objects, delete the inactive objects that occupy the memory and move the active objects to the bottom of heap until all the active objects are moved to the heap side.
Advantage: you do not need to divide from sapce and to space to improve memory usage. In addition, the memory space after compaction is allocated continuously.
Disadvantage: this algorithm is relatively complex.
Sun jdk gc introduction:
Before reducing GC, let's take a look at a set of statistics from IBM:
98% of Java objects become inactive soon after they are created. only 2% of objects remain active for a long time.

If the two objects can be differentiated, the GC efficiency will be submitted. In Sun jdk gc (specifically, after JDK), a GC policy with different lifecycles is proposed.

Young generation:
Objects with short lifecycles are classified as young generation. Due to the short life cycle, many of these objects become inactive during GC. Therefore, for young generation objects, the copy algorithm only needs to copy a small number of surviving objects to space. The smaller the number of surviving objects, the higher the efficiency of the copy algorithm.
The GC of young generation is called minor GC. After several times of minor GC, the surviving objects will be removed from young generation and moved to tenured generation (which will be introduced below)

Young generation is divided:
EDEN: whenever an object is created, it is always allocated in this area.
Copying vor1: from space in the copy Algorithm
Secondary vor2: To sapce in the copy algorithm (note: the identities of secondary vor1 and secondary vor2 are exchanged after each minor GC)
During minor GC, the Eden + movie vor1 (2) object will be copied to movie vor2 (1.
Tenured generation:
Objects with a long life cycle are classified into tenured generation. Generally, objects that are still alive after multiple minor GC operations will be moved to tenured generation. (Of course, in minor GC, if the number of surviving objects exceeds the capacity of zoovor, the objects that cannot be stored will be directly migrated to tenured generation)
The GC of tenured generation is called Major GC, which is generally called full GC.

The compactiion algorithm is used. Because the tenured generaion area is relatively large and the object lifecycle is common, compaction takes some time. Therefore, the GC time for this part is relatively long.
Minor GC may cause full GC. When the space of Eden + from space is larger than the remaining space in the tenured generation area, full GC is triggered. This is a pessimistic algorithm. To ensure that all objects in Eden + from space survive, there must be enough tenured generation space to store these objects.
Permanet generation:
This region is relatively stable and mainly used to store classloader information, such as class information and method information.
This region requires sufficient space for spring hibernate frameworks that require dynamic type support.

This part of content is relatively theoretical, and can be combined with jstat, jmap and other commands (of course, jconsole, jprofile, gciewer and other tools can also be used) to observe the jdk gc situation

JVM (2) Understanding