Get the App
SLTechnology News&Howtos  ›  Internet Technology  › 

JVM Series 2: GC Strategy & memory Application, object Aging

Shulou Source: shulou.com Published: 2022-06-03 07:07:02 09月25日 Update

JVM Series 2: GC Strategy & memory Application, object Aging

There are many algorithms for GC (GarbageCollection) in JVM, such as tag removal collector, compression collector, generational collector and so on. For more information, please see the types of HotSpotVMGC.

Generational collection is now more commonly used, that is, memory is divided into several regions, and objects with different lifecycles are placed in different areas: younggeneration,tenuredgeneration and permanetgeneration. Most of the objec is assigned to younggeneration (short life cycle), and most of the object is die here. When the younggeneration is full, minorcollection (YGC) is thrown. Object that survives after minorcollection is moved to tenuredgeneration (with a longer life cycle). Finally, majorcollection is triggered when the tenuredgeneration is full. Majorcollection (Fullgc) triggers the recycling of the entire heap, including the recycling of younggeneration. The permanetgeneration area is relatively stable, mainly storing classloader information.

Younggeneration consists of eden and 2 survivor regions. One of the survivor areas is always empty and is the destination of the objecy where the eden region and another survivor region are alive after the next copycollection. The object is copied in the survivo area until it is transferred to the tenured area.

We should try to reduce the number of Fullgc (tenuredgeneration is generally large, collection time is long, frequent Fullgc will seriously affect the performance of the application).

Heap memory GC

JVM (using generational recycling strategy) YGC young objects (younggeneration) with a higher frequency, while FullGC older objects (tenuredgeneration) less frequently (after the tenuredgeneration is full). This eliminates the need for GC to check all the objects in memory every time.

Non-heap memory not GC

GC does not clean up PermGenSpace during the run time of the main program, so if you have a lot of CLASS in your application (especially dynamically generated classes, of course, permgenspace storage is not limited to classes), PermGenSpace errors are likely to occur.

Memory request, object aging process

I. memory request process

JVM attempts to initialize a memory region in Eden for related Java objects

When there is enough Eden space, the memory request ends. Otherwise, to the next step,

JVM attempts to release all inactive objects in Eden (minorcollection secondary collection). If there is still not enough Eden space to put new objects after release, it attempts to put some active objects in Eden into the Survivor area.

The Survivor area is used as the intermediate exchange area between Eden and old. When there is enough space in the OLD area, the objects in the Survivor area will be moved to the Old area, otherwise they will be retained in the Survivor area.

When there is not enough space in the old area, JVM will do majorcollection (full collection) in the old area.

After complete garbage collection, if the Survivor and old areas are still unable to store some objects copied from Eden, resulting in JVM being unable to create memory areas for new objects in the Eden area, a "Outofmemory error" will occur.

Second, the aging process of the object

The memory of newly created objects is allocated from eden. The process of Minorcollection is to copy the eden and the living objects in the survivorspace into the free survivorspace. After an object has experienced a certain number of minorcollection in the younggeneration (which can be configured through parameters), it is moved to the oldgeneration, called tenuring.

GC trigger condition

What happens when the GC type trigger condition is triggered? pay attention to the viewing mode. There is not enough YGCeden space.

Clear the memory occupied by all noref objects in Eden+fromsurvivor

Copy all living objects in eden+fromsur to tosur

Some objects will be promoted to old:

Tosur can't put it down.

The number of survivals exceeds that in turningthreshold.

Recalculate tenuringthreshold (serialparallelGC triggers this item)

Resize Eden and from (parallelGC triggers this)

Suspend the application in the whole process

Whether it is multithreaded or not depends on the specific GC to determine the jstat-gcutil

GclogFGC

Insufficient old space

Insufficient perm space

Displays the timing trigger for calling System.GC,RMI, etc.

Pessimistic Strategy in YGC

Memory information of dumplive (jmap-dump:live)

Clear the object of noref in heap

Class information loaded in classloader that has been unloaded in permgen

If CollectGenOFirst is configured, YGC is triggered first (for serialGC)

If ScavengeBeforeFullGC is configured, YGC is triggered first (for serialGC)

Suspend the application in the whole process

Whether it is multithreaded or not is decided by the specific GC

Whether to compress depends on the specific GCjstat-gcutil configured.

Running out of gclogpermanentgeneration space will cause FullGC, and still not enough will cause PermGenSpace errors. The purpose of tuning is to minimize triggering FGC.

Tags: Object memory area space process application configuration aging strategy information cycle times life part error collector different insufficient whole process condition Apple Docker Huawei Linux macOS MariaDB Microsoft MySQL NVidia OPPO Reno macOS MySQL Xiaomi OPPO Reno Docker