Conditions that trigger the JVM to perform Full GC and strategies for dealing with them

Collecting memory from a young generation space (including Eden and Survivor regions) is called a Minor GC, a Major GC for older generations, and a Full GC for the entire heap. In recent JDK versions, collection of immortal belts (or method areas) is included by default, and a Full GC is usually accompanied by at least one Minor GC, but not always. Major GC is typically 10 times slower than Minor GC. Let’s take a look at what kind of situation triggers the JVM to do Full GC and how to deal with it.

1. Call the system.gc () method

This method is called to suggest that the JVM do Full GC, although it is a recommendation rather than a rule, but in many cases it triggers Full GC, increasing the frequency of Full GC and thus the number of intermittent pauses. It is recommended that you do not use this method and let the vm manage its memory by passing -xx :+ DisableExplicitGC to disable RMI calling System.gc.

Old generation space is insufficient

The old space is empty only when the new generation object is rolled in and created as a large object or array. If the old space is still empty after the Full GC, the following error is raised:

java.lang.OutOfMemoryError: Java heap space

To avoid Full GC due to both of these conditions, tune so that objects are collected during the Minor GC phase, live longer in the new generation, and don’t create objects and arrays that are too large.

3. Insufficient space in the eternal life area

Permanet Generation stores some class information, constants, static variables and other data. When there are too many classes to load, reflected classes and called methods in the system, The Permanet Generation may be Full and perform Full GC even if it is not configured to adopt CMS GC. If the Full GC fails, the JVM throws the following error message:

java.lang.OutOfMemoryError: PermGen space

To avoid Full GC, increase the Perm Gen space or switch to CMS GC.

4. Promotion failed and Concurrent mode failure occur during CMS GC

For programs using CMS for older GC, pay particular attention to the presence of promotion failed and Concurrent mode failure in the GC logs, which may occur when these two conditions occur

The Full GC is triggered.

Promotion failed is caused when a Minor GC fails to place survivor Spaces and objects can only be placed in older ages. Concurrent mode failure occurs when

When a CMS GC is running out of space, an object needs to be put into the old age. (Sometimes “out of space” is caused by too much floating garbage at the time of the CMS GC that temporarily runs out of space to trigger Full GC.)

In JDK 5.0+, 6.0+, CMS may finish remark because of JDK BUG29

After a long time to trigger the sweeping action. For this kind of situation, can be set up through – XX: CMSMaxAbortablePrecleanTime = 5 (in ms) to avoid.

5. The average size of the Minor GC promoted to the old generation is larger than the remaining space of the old generation

This is a complicated trigger case and Hotspot makes a judgment when performing a Minor GC to avoid running out of space in the old generation due to new generation objects being promoted to the old generation

The average size of the Minor GC promoted to the old generation from the previous statistics is greater than the remaining space of the old generation, which triggers the Full GC directly.

For example, if a 6MB object is promoted to the old generation after the first Minor GC is triggered, the next Minor GC is checked to see if the remaining space in the old generation is greater than 6MB. If it is less than 6MB,

The Full GC is executed.

When the Cenozoic generation uses the PS GC, the method is slightly different. The PS GC also checks after the Minor GC, as in the example above, after the first Minor GC, the PS GC checks to see if there is any space left in the previous generation

If the value is greater than 6MB, recycling of the old generation is triggered.

In addition to the above four cases, Sun JDK applications that use RMI for RPC or administration perform Full GC once an hour by default. This can be done by passing -java – at startup

Dsun. Rmi. DGC. Client. GcInterval = 3600000 to set up the Full GC execution time interval or through – XX: + DisableExplicitGC to prohibit rmi System. GC.

6. Large objects allocated in the heap

Large objects are Java objects that require a large amount of contiguous memory space, such as a very long array. Such objects go straight to the old age, where there is a large amount of free space but no contiguous space can be found to allocate to the current object. In this case, the JVM is triggered to perform Full GC.

In order to solve this problem, the CMS garbage collector provides a configurable parameters, namely – XX: + UseCMSCompactAtFullCollection switch parameters, is used to “enjoy” after Full GC service, additional free gift of a defragmentation process cannot concurrent process of memory consolidation, The problem of space debris, but the teton may not be the same time, the JVM designers also provides another parameter – XX: CMSFullGCsBeforeCompaction, this parameter is used to set how much time without compression in the implementation of the Full GC, followed by a band of compression.