Shulou(Shulou.com)06/02 Report--

This article shows you what are the common parameter configurations of jvm, which are concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Use the-XX:+UnlockExperimentalVMOptions-XX:+UseJVMCICompiler parameter to enable the Graal compiler.

Print initialization parameters:

Java-XX:+PrintFlagsInitial

Java-ea TestAssert is used to set whether jvm starts the assertion mechanism (supported since JDK 1.4), and jvm turns off the assertion mechanism by default.

-XX:ReservedCodeCacheSize=240m JIT compiled code cache size

-XX:SoftRefLRUPolicyMSPerMB=50 defaults to 1000ms. Soft reference lifetime. After that, it will be recycled at the next garbage collection.

Clock-timestamp-XX:NewSize=256m-XX:MaxNewSize=256m

Set the new generation memory size of JVM (- Xmn sets NewSize to be the same as MaxNewSize. 256m).

XX:+HeapDumpOnOutOfMemoryError allows virtual machines to automatically generate heap dump snapshot files after a memory overflow exception occurs

Set the ratio of the Cenozoic (including Eden and two Survivor zones) to the old (excluding the persistent generation). When set to 3, the ratio of the Cenozoic to the old is 1:3, and the Cenozoic accounts for 1 of the whole stack.

-XX:NewRatio=3

If set to 8, the ratio of two Survivor regions to one Eden region is 2:8, and one Survivor region accounts for 10% of the whole Cenozoic era.

-XX:SurvivorRatio=8

Eden memory size setting: the memory size of the new generation minus 2*Survivor is the size of Eden.

Stack (stack) memory size setting

-Xss1m each thread generates a stack. Decreasing this value generates more threads under the same physical memory. If this value is too small, it will affect the depth of the method call.

Method area memory allocation (used in previous versions of JDK8, no persistent generation in JDK8, MetaSpace used)

-XX: PermSize=128m sets persistent memory size of 128m instead of initial memory size

-XX:MaxPermSize=512m sets the persistent generation maximum memory size of 512MB

Metaspace (Metaspace) (JDK8) defaults to 20m

-XX:MetaspaceSize=128m-XX:MaxMetaspaceSize=512m (JDK8)

The persistence generation of JDK8 can use up almost all the memory of the machine. Also set an initial value of 128m and a maximum value of 512m to protect it.

-XX:MaxMetaspaceSize: sets the maximum metaspace. The default is-1, that is, there is no limit, or only limited to the local memory size.

-XX:MetaspaceSize: specifies the initial space size of the metaspace, in bytes. Reaching this value will trigger garbage collection for type unloading, and the collector will adjust the value: if a large amount of space is freed, the value will be lowered appropriately; if very little space is freed, increase the value appropriately if not more than-XX:MaxMetaspaceSize (if set)

-XX:MinMetaspaceFreeRatio: the function is to control the percentage of the minimum metaspace remaining capacity after garbage collection, which can reduce the frequency of garbage collection due to insufficient metaspace.

Similarly,-XX:Max-MetaspaceFreeRatio is used to control the percentage of the maximum meta-space remaining capacity.

There are two main parts of garbage collection in the method area: obsolete constants and types that are no longer used. Recycling obsolete constants is very similar to recycling objects in the Java heap. Take an example of literal recycling in a constant pool, if a string "java" has ever entered the constant pool.

But the current system does not have a string object whose value is "java". In other words, no string object references the "java" constant in the constant pool, and there is no other place in the virtual machine to refer to this literal quantity. If memory reclaim occurs at this time, and

If the garbage collector determines that it is necessary, the "java" constant will be cleaned out of the constant pool by the system. Symbolic references to other classes (interfaces), methods, and fields in the constant pool are similar.

-Xnoclassgc means to turn off JVM's garbage collection of method area classes

Direct ByteBuffer (Direct memory) memory size setting

-XX:MaxDirectMemorySize

Set the age of the new generation to enter the old age

-XX:MaxTenuringThreshold=15

(in bytes) objects with a size greater than 1024 bytes are allocated directly in the old age. The-XX:PretenureSizeThreshold parameter is only valid for two new generation collectors, Serial and ParNew, HotSpot.

Other new generation collectors, such as Parallel Scavenge, do not support this parameter If you must use this parameter for tuning, consider the collector combination of ParNew and CMS.

-XX:PretenureSizeThreshold=1024

The percentage of TLAB in the eden zone defaults to 1%

-XX:TLABWasteTargetPercent = 1

So add the parameter-XX:+DisableExplicitGC to eclipse.ini to shield out System.gc ().

Garbage collection

Matching strategy

As an old collector, CMS can not work with the new generation collector Parallel Scavenge that already exists in JDK 1.4.0.

Serial + Serial Old (commonly used by clients)-XX: + UseSerialGC

ParNew + Serial Old (rarely used)-XX: not supported after + UseParNewGC jdk9

Serial + CMS (rarely used)

ParNew + CMS (commonly used in jdk5) + (concurrent failed Serial Old)

-XX:+ UseConcMarkSweepGC-XX:+UseCMS-CompactAtFullCollection-XX:CMSFullGCsBefore-Compaction=6

-XX:CMSInitiatingOccupancyFraction=70 CMS garbage collector triggers CMS garbage collection when the old age reaches 70%.

Parallel Scavenge + Serial Old-XX:+UseParallelGC

Parallel Scavenge + Paraller Old (commonly used in jdk6)-XX:+UseParallelOldGC

G1-XX: + UseG1GC

ZGC usage

-XX:+UnlockExperimentalVMOptions-XX:+UseZGC XX:+UseNUMA

Epsilon-XX:+UnlockExperimentalVMOptions-XX:+UseEpsilonGC

The Epsilon collector cannot perform garbage collection as a "selling point" garbage collector

The ParNew collector is the default new generation collector when CMS is activated (using the-XX:+UseConcMarkSweepGC option), or you can use the-XX:+/-UseParNewGC option to force it to be specified or disabled. So since JDK 9, the combination of ParNew and CMS collectors is no longer the officially recommended collector solution in server-side mode. Officials hope that it will be completely replaced by G1, and even cancel the support for the combination of ParNew and Serial Old and Serial plus CMS (which is rarely used in the past), and directly cancel the-XX:+UseParNewGC parameter, which means that ParNew and CMS can only be used with each other, and no other collectors can match them.

ParNew collector

-XX:ParallelGCThreads parameter to limit the number of threads for garbage collection.

Parallel Scavenge collector

The Parallel Scavenge collector provides two parameters for precise control of throughput, the-XX:MaxGCPauseMillis parameter that controls the maximum garbage collection pause time and the-XX:GCTimeRatio parameter that directly sets the throughput size.

The value allowed for the-XX:MaxGCPauseMillis parameter is a number of milliseconds greater than 0, and the collector will try its best to ensure that the time spent on memory collection does not exceed the user-set value.

The value of the-XX:GCTimeRatio parameter should be an integer greater than 0 and less than 100, that is, the ratio of garbage collection time to total time. For example, if you set this parameter to 19, the maximum allowed garbage collection time is 5% of the total time (that is, 1 / (1-19)), and the default value is 99, that is, a maximum of 1% (1 / (1-99)) garbage collection time is allowed.

-XX:+UseAdaptiveSizePolicy. This is a switch parameter. When this parameter is activated, there is no need to manually specify detailed parameters such as the new generation size (- Xmn), the ratio of Eden to Survivor (- XX:SurvivorRatio), and the promotion age object size (- XX:PretenureSizeThreshold). The virtual machine collects performance monitoring information according to the operation of the current system, and dynamically adjusts these parameters to provide the most appropriate pause time or maximum throughput. This regulation is called adaptive tuning strategy for garbage collection (GC Ergonomics).

The CMS collector provides a-XX:+UseCMS-CompactAtFullCollection switch parameter (on by default, which has been deprecated since JDK 9) memory consolidation is turned on when fullGC.

-XX:CMSFullGCsBefore-Compaction (this parameter is obsolete from JDK 9). The purpose of this parameter is to require the CMS collector to defragment before entering FullGC next time after performing FullGC that does not defragment space several times (the number of parameters is determined by the parameter value) (default is 0, which means defragmentation occurs every time you enter FullGC).

Increase the value of the parameter-XX:CMSInitiatingOccu-pancyFraction to increase the trigger percentage of CMS to reach that percentage for garbage collection. By JDK 6, the startup threshold of the CMS collector has been raised to 92% by default. But this makes it easier to face another risk: if the memory reserved during the CMS run does not meet the needs of the program to allocate new objects, there will be a "concurrency failure" (Concurrent Mode Failure). At this time, the virtual machine will have to start a backup plan: freeze the execution of user threads and temporarily enable the Serial Old collector to restart the old garbage collection, but the pause will be very long.

G1 collection

Use the parameter-XX:MaxGCPauseMillis to specify, default is 200ms), give priority to those Region with the greatest recovery value, and set the allowable collection pause time

The size of each Region can be set by the parameter-XX:G1HeapRegionSize, the value range is 1MB~32MB, and should be 2 to the N power.

Class unloading is not supported at this time (not supported by JDK at 11:00, but already supported by ZGC in JDK 12)

Log:

-Xlog [: [selector] [: [output] [: [decorators] [: output-options]

The most critical parameter on the command line is the Selector, which consists of a tag (Tag) and a log level (Level), and the tag name of the garbage collector is "gc".

The signatures of all supported gc functional modules are as follows

Add,age,alloc,annotation,aot,arguments,attach,barrier,biasedlocking,blocks,bot,breakpoint,bytecode

In addition, you can use a Decorator to require that each line of log output be appended with additional content, and the information supported to attach to the log line includes:

Time: current date and time.

Uptime: the elapsed time, in seconds, since the virtual machine was started.

Timemillis: the number of milliseconds in the current time, equivalent to the output of System.currentTimeMillis ().

Uptimemillis: the number of milliseconds that have elapsed since the virtual machine started.

Timenanos: the number of nanoseconds in the current time, equivalent to the output of System.nanoTime ().

Uptimenanos: the number of nanoseconds that have elapsed since the virtual machine was started.

Pid: process ID.

Tid: thread ID.

Level: log level.

If it is not configured, the default is:

-Xlog:all=warning:stdout:uptime,level,tags

-XX:+UseG1GC-Xms20M-Xmx20M-Xmn10M-Xlog:all=info:stdout:uptime,level,tags,time

-Xlog [: [what] [: [output] [: [decorators] [: output-options [,...]

-Xlog:gc*=info, which means that all logs containing gc tags will be output at info level, that is, all gc-related tags mentioned above.

-XX:+UseG1GC-Xms20M-Xmx20M-Xmn10M-Xlog:gc*=info:stdout:time,uptime,tags

Output

Contains three types of output:

* stdout: standard output

* stderr: standard error output

* file=filename output to file

Output-options:filecount=50,filesize=100M can be configured for output to files, which means that 50 files are retained, each 100m

Java-Xlog:gc GCTest

To view basic GC information, use-Xlog:gc after-XX:+PrintGC,JDK 9 before JDK 9:

View the GC details, use-XX:+PrintGCDetails before JDK 9, use-X XX:+PrintGCDetails log after JDK 9, print out all the subdivision processes under the GC tag with the wildcard * if you adjust the log level to Debug or Trace

Check the available capacity changes of heap and method area before and after GC, and use-Xlog:gc+heap=debug after using-XX:+PrintHeapAtGC,JDK 9 before JDK 9:

Check the concurrency time and pause time of user threads during GC, using-XX:+Print-GCApplicationConcurrentTime before JDK 9 and-Xlog:safepoint java-Xlog:safepoint GCTest after-XX:+PrintGCApplicationStoppedTime,JDK 9

Check out the information about the automatic adjustment of the collector Ergonomics mechanism (automatically setting heap space generation area size, collection target, etc., and supporting it from the Parallel collector). Use-Xlog:gc+ergo*=trace: java-Xlog:gc+ergo*=trace GCTest after-XX:+PrintAdaptive-SizePolicy,JDK 9 before JDK 9

Check the age distribution information of the remaining objects after passing the collection. Use-XX:+PrintTenuring-Distribution,JDK 9 before JDK 9 and then use-Xlog:gc+age=trace: java-Xlog:gc+age=trace GCTest

-verbose:gc enables GC log

-XX:+PrintGCDetails-Xloggc:./gc.log-XX:+PrintGCDateStamps enters GC log details into gc.log

However, after adding the parameter-XX:+PrintGCApplicationStoppedTime-XX:+PrintGCDate-Stamps-Xloggc:gclog.log, it is confirmed from the collector log file that the pause is indeed caused by garbage collection, most of the collection time is controlled within 100ms, but occasionally there is a long collection process that is close to 1 minute.

To avoid this phenomenon in Java's GUI program, you can add the parameter "- Dsun.awt.keepWorkingSetOnMinimize=true" to solve it. This parameter is used in many AWT programs, such as VisualVM that comes with JDK (once), and is found in the startup configuration file.

So first add the parameters-XX:+PrintSafepointStatistics and-XX:PrintSafepointStatisticsCount=1 to check the security log.

Add two parameters,-XX:+SafepointTimeout and-XX:SafepointTimeoutDelay=2000, to make the virtual machine consider it a timeout when the thread enters the safe point for more than 2000 milliseconds, which will output the name of the thread that caused the problem.

We already know that the security point is selected according to the principle of "whether it has the characteristics of letting the program execute for a long time", so method calls, loop jumps, and abnormal jumps may all have security points, but the HotSpot virtual machine also has an optimization measure for loops in order to avoid excessive burden caused by too many security points. It is considered that if the number of cycles is small, the execution time should not be too long. So using the int type or scope is smaller

Loops with data types as index values are not placed at safe points by default Such loops are called countable loops (Counted Loop), and correspondingly, loops that use long or a wider range of data types as index values are called uncountable loops (Uncounted Loop) and will be placed at safe points. In general, this optimization is feasible, but the execution time of the loop is not only determined by its number of times, if the loop body is particularly slow in a single execution, then even countable loops may take a lot of time.

What are the above contents of jvm common parameter configuration? have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.