preface

❝

I looked up a lot of articles on how to configure JVM parameters on the Internet, but I didn’t get a specific specification for how to configure JVM parameters in production environments. Sure, it can be difficult to set the right JVM parameters for a production environment due to various factors, but this article will give you a reasonable parameter setting guideline.

❞

In this paper, the main line

(1) Analysis of JVM runtime data area

Note when setting JVM parameters

(3) Simple description of GC garbage collection process

4. Final JVM parameter configuration guide

This article is reprinted by JdK1.8 — JVM analysis and tuning

JVM runtime data area analysis

❝

The following will focus on the JVM runtime data area under the “1.7 and 1.8” JDK versions.

❞

JDK1.7 and before

Prior to JDK 1.7, Java class information, constant pools, and static variables were stored in Perm (permanent generation). Class metadata and static variables are allocated to Perm when the class is loaded and removed from Perm when the class is unloaded by the garbage collector.

JDK1.8

The changes to the JVM architecture in JDK 1.8 put class metadata “in local memory” and, in addition, “constant pools and static variables” in the Java heap. The HotSopt VM will explicitly allocate and free local memory for the metadata of the class.

Under this architecture, class meta information breaks the limit of the -xx :MaxPermSize maximum method area size parameter, so the JVM configuration parameter of PermSize is also invalid, and more local memory can now be used.

This partially solves the problem of generating a large number of “class instances” at run time using reflection, proxy, etc., which greatly reduces the problem of triggering Full GC and the problem of “OutOfMemoryError: PermGen” method area memory overflow.

Part of the JVM runtime data area for JDK1.7 is shown


Contents of dry goods:

One of the most obvious changes you can see is the shift of meta-space from “virtual machine to local memory”; By default, the size of a meta-space is limited only by local memory. This means that OOM exceptions will almost never be thrown in the future for running out of permanent generation space.

Classes and JAR packages in pre-jdk 1.8 are stored under permGen. PermGen sizes are fixed, and projects cannot share public classes, so you can easily get OOM exceptions.

After being converted to metaSpaces, various projects share the same class memory space. For example, after multiple projects reference apache-common package, metaSpaces stores only one apache-common class, which improves memory utilization and garbage collection efficiency.

Notes for JVM parameter Settings

1. Before jdk1.7, the production environment generally has the following configuration:

-XX:PermSize=512M -XX:MaxPermSize=1024M

Copy the code

The permanent generation (method area) area that represents the Java class information stored in the JVM, constant pool, and static variables has an initial size of 512MB and a maximum size of 1024MB. This value is fixed after the project is started, and if the project has too many classes, it is likely to cause OutOfMemoryError: PermGen exceptions.

After upgrading JDK1.8, the above perm configuration has changed to:

-XX:MetaspaceSize=512M XX:MaxMetaspaceSize=1024M

Copy the code

MetaspaceSize MetaspaceSize MetaspaceSize MetaspaceSize MetaspaceSize MetaspaceSize MetaspaceSize

jinfo -flag MetaspaceSize 1234  -xx :MetaspaceSize=21807104

jinfo -flag MaxMetaspaceSize 1234 -xx :MaxMetaspaceSize=18446744073709547520

Copy the code

Contents of dry goods:

MetaspaceSize Specifies the threshold for triggering FullGC. The default threshold is 21 MB. If the MetaspaceSize is configured, the minimum threshold is a user-defined value. When the space usage threshold is reached, FullGC is triggered and the value is expanded. Of course, if the actual use of the meta-space is less than the threshold, this value will also be reduced during GC.

MaxMetaspaceSize is the maximum value of the meta space. If set to too small, this will be the same as above and may result in frequent FullGC and even OOM.

GC garbage collection process

Firstly, attach a large picture extracted from the Internet, which can explain the process of GC more clearly:


Garbage collection process:

❝

In the following GC process, the condition for the objects in the new generation to be promoted to the old generation is the “age threshold”; There are many other qualifications for promotion, more on that later.

❞

① New objects are placed in Eden.

② Remember that the GC algorithm of the new generation is “copy algorithm”. Minor GC is triggered when the Eden sector is full or nearly full. At the beginning of GC, objects only exist in the Eden zone and in a Survivor zone named “From”, where the Survivor zone “To” is empty. Following the GC, all surviving objects in Eden are copied To the “To” zone, and in the “From” zone, surviving objects are decided where To go based on their age.

3. Objects whose age reaches a certain value (the age threshold can be set by “-xx :MaxTenuringThreshold”, the default value is “15”) will be moved To the aged generation. Objects that do not reach the threshold will be copied To the Survivor area.

④ After this GC, Eden area and From area have been emptied. At this point, “From” and “To” switch roles, so that the new “To” is the “From” before the last GC, and the new “From” is the “To” before the last GC.

In any case, the Survivor region named “To” is guaranteed To be empty. The Minor GC repeats this process until the “To” section is filled, and when the “To” section is filled, all objects are moved To the aged generation.

⑥ Note: When triggering a Minor GC, if it is found that there is more space left in the old generation than there is in the current generation, it will trigger a Full GC instead of triggering a Minor GC.

❝

Cleaning up the new generation (Eden and Survivor) is called Minor GC; Cleaning the Old generation is called the Major GC; Cleaning up the entire heap space (young and old) as well as the permanent generation (method area) is called Full GC.

❞

Here’s another big picture to understand the GC process:

Conditions for the new generation to be promoted to the old generation:

① If the size of the object is more than half that of Eden, it will be allocated to the old generation directly; if old cannot be allocated, a major GC will be performed; if the object is less than half that of Eden but there is not enough space, a minor GC will be performed, that is, the new generation GC.

②, After minor GC, Survivor will be placed in the Old age.

(3) Dynamic age judgment: objects older than or equal to a certain age exceed half of Survivor space, and objects older than or equal to a certain age directly enter the old age.

JVM Parameter Configuration Guide

The first three sections provided an overview of the JVM, followed by the focus of this article.

-XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M -Xms256m -Xmx256m

Copy the code

Set the initial value and maximum value of the metadata space. Set the initial value and maximum value of the heap space.

Why is MetaspaceSize set to 128M? Why is the initial heap memory Xms set to 256M instead of 512M?

Follow the Java official guidelines:

Java heap size, Xms and Xmx are set to 3-4 times the memory usage of old age objects after Full GC.

② Set PermSize and MaxPermSize to 1.2-1.5 times that of the old generation object.

③ The setting of Xmn in the young generation is 1-1.5 times that of the surviving object in the old age.

(4) The memory size of the old age is set to 2-3 times that of the surviving objects of the old age.

After running the test with a mock build environment for some time, the JVM parameter data is retrieved. Then set the actual JVM parameters; Use the jstat tool to view the JVM as follows:

jstat -gc 12345

# # #

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   

13824.0 22528.0 13377.0  0.0   548864.0 535257.2  113152.0   46189.3   73984.0 71119.8 9728.0 9196.2     14    0.259   3      0.287    0.546



Copy the code

OU indicates that the memory occupied by the old years is 46189.3K (about 45M). The JVM configuration parameters should be modified as follows:

-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M -Xms180m -Xmx180m

Copy the code

Follow + like + favorite + comment yo

If this article is helpful to you, please wave your love to make a fortune of the little hand under the praise ah, your support is my continuous creation of power, thank you!

You can VX search [Muzi-lei] public number, adhere to the high quality of original Java technology articles, is worth your attention!