Shulou(Shulou.com)05/31 Report--

This article is to share with you what happens when JVM is triggered for Full GC. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Heap memory is divided into Eden, Survivor, and Tenured/Old space, as shown in the following figure:

Reclaiming memory from younger generation space (including Eden and Survivor areas) is called Minor GC, for older GC is called Major GC, and Full GC is for the entire heap. In recent versions of JDK, the collection of immortal bands as method zones is included by default (there is no immortal belt in JDK8), and Full GC is often accompanied by Minor GC at least once, but not absolutely. Major GC is generally more than 10 times slower than Minor GC. Let's take a look at what triggers JVM to Full GC and coping strategies.

1. The call to the System.gc () method

The call to this method advises JVM to Full GC, although it is only recommended rather than certain, but in many cases it triggers Full GC, increasing the frequency of Full GC, that is, increasing the number of intermittent pauses. Strong impact is recommended not to use this method, let the virtual machine to manage its own memory, you can use-XX:+ DisableExplicitGC to prevent RMI from calling System.gc.

2. Lack of space for the elderly generation.

The shortage of old space occurs only when the new generation of objects are transferred and created as large objects or large arrays. When the space is still insufficient after the execution of Full GC, the following error is thrown:

Java.lang.OutOfMemoryError: Java heap space

In order to avoid Full GC caused by the above two conditions, we should try our best to allow objects to be recycled in the Minor GC phase, to allow objects to survive in the new generation for a longer period of time, and not to create too large objects and arrays.

3. there is insufficient space in the immortal zone.

The method area in the runtime data area of the JVM specification is also used to be called the eternal generation or eternal zone in the HotSpot virtual machine. Some class information, constants, static variables and other data are stored in Permanet Generation. When there are many classes to be loaded, reflected classes and methods called in the system, Permanet Generation may be full, and Full GC will be executed without being configured to use CMS GC. If it still fails to recycle after Full GC, JVM will throw the following error message:

Java.lang.OutOfMemoryError: PermGen space

In order to avoid the Full GC phenomenon caused by full Perm Gen, the method that can be adopted is to increase the Perm Gen space or switch to using CMS GC.

4. Promotion failed and concurrent mode failure appear in CMS GC

For programs that use CMS for old GC, pay special attention to whether there are promotion failed and concurrent mode failure conditions in the GC log, when these two conditions occur

The Full GC will be triggered.

Promotion failed is caused by the fact that survivor space cannot be put down and objects can only be put into the old age when Minor GC is carried out; concurrent mode failure is caused by the fact that the old age can not be put down either.

During the execution of CMS GC, there are also objects that need to be put into the old age, which is caused by a lack of space (sometimes "insufficient space" is caused by too much floating garbage at the time of CMS GC, which causes a temporary shortage of space to trigger Full GC).

The measures to be taken are: increase the survivor space, old age space or reduce the ratio of triggering concurrent GC, but in the versions of JDK 5.0 + and 6.0 +, it is possible that CMS ends in remark due to the bug29 of JDK

It takes a long time to trigger the sweeping action. This situation can be avoided by setting-XX: CMSMaxAbortablePrecleanTime=5 (unit is ms).

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

This is a more complex trigger situation. In order to avoid the shortage of space in the old generation due to the promotion of the new generation of objects to the old generation, Hotspot made a judgment when conducting Minor GC, if

If the average size of the Minor GC promoted to the old generation is larger than the remaining space of the old generation, then the Full GC will be triggered directly.

For example, after the program triggers Minor GC for the first time, the object with 6MB is promoted to the old generation, then when the next Minor GC occurs, first check whether the remaining space of the old generation is greater than 6MB, if less than 6MB

Then Full GC is executed.

When the new generation adopts PS GC, the method is slightly different. PS GC will also be checked after Minor GC. For example, after the first Minor GC in the above example, PS GC will check whether the remaining space of the old generation

Greater than 6MB, if less, triggers the recycling of the old generation.

In addition to the above four situations, for Sun JDK applications that use RMI for RPC or management, Full GC is performed once an hour by default. Can be done by-java-at startup

Dsun.rmi.dgc.client.gcInterval=3600000 to set the interval between Full GC execution or-XX:+ DisableExplicitGC to prevent RMI from calling System.gc.

6. Large objects are allocated in the heap

The so-called large object refers to the java objects that need a lot of continuous memory space, such as a very long array, which will directly enter the old age, while in the old age, although there is a lot of remaining space, but can not find enough continuous space to be allocated to the current object, this situation will trigger JVM to Full GC.

To solve this problem, the CMS garbage collector provides a configurable parameter, the-XX:+UseCMSCompactAtFullCollection switch parameter, which is used to give away an additional free defragmentation process after "enjoying" the Full GC service. The memory defragmentation process cannot be concurrently, and the space debris problem is gone, but the Teton time has to be longer. JVM designers also provide another parameter-XX:CMSFullGCsBeforeCompaction, which is used to set the number of times an uncompressed FullGC is executed, followed by one with compression.

Thank you for reading! This is the end of this article on "what triggers JVM to Full GC". I hope the above content can be of some help to you, so that 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.