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

This article mainly explains "the introduction of Java garbage collector and JVM tuning method". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the introduction of Java garbage collector and JVM tuning method".

Garbage collector

1.Serial

Concern: stw's time replication algorithm STW

2.ParNew

Concern: time of stw multithreaded version replication algorithm STW of Serial

Parameter-number of XX:ParallelGCThreads parallel threads

3.Parallel Scavenge

Concern: achieving a controllable Throughput (Throughput first) replication algorithm Throughput is the ratio of the time CPU spent running user code to the time consumed by CPU, that is, throughput = time to run user code / (time to run user code + garbage collection time).

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

Parameters.

-XX:MaxGCPauseMillis-XX:GCTimeRatio-XX:+UseAdaptiveSizePolicy adaptive adjustment strategy

Old area

1.Serial Old

The old version of Serial, JDK1.5, can be used with Parallel Scavenge before using Mark-Compact when Concurrent mode failure occurs in CMS

2.Parallel Old

The old version of Parallel Scavenge, JDK1.6, appeared with Parallel Scavenge and used Mark-Compact.

3.CMS

-XX:+UseConcMarkSweepGCMark-Sweep process: initial marking concurrent marking and clearing initial marking and re-marking STW takes the longest time is concurrent marking and concurrent clearing default number of recycled threads: the default number of recycled threads started by CMS is (ParallelGCThreads + 3) / 4) Advantages can be set through-XX:ParallelCMSThreads=20: concurrency low pause disadvantages: 1. Very sensitive to CPU resources, consuming some threads (CPU resources) causes the application to slow down, throughput decreases by default threads = (number of CPU + 3) / 42, unable to handle floating garbage, Concurrent mode failure may occur, which may lead to another fullGC generation parameter-XX:CMSInitiatingOccupancyFraction default 68% CMS trigger percentage, during CMS execution, reserved space cannot be met. There will be Concurrent mode failure failure, and the solution of starting backup SerialOld will pause for a longer time. (so CMSInitiatingOccupancyFraction cannot be set too large) 3. Memory fragmentation parameter-XX:+UseCMSCompactAtFullCollection (extended pause time) is on by default-XX:CMSFullGCsBeforeCompaction (how many times non-defragmented FullGC is performed once with compression) parallelization of other parameters initial tags-XX:+CMSParallelInitialMarkEnabled to reduce the second pause time, turn on parallel remark:-XX:+CMSParallelRemarkEnabled, if the remark is still too long You can enable-XX:+CMSScavengeBeforeRemark (start ygc before CMS GC to reduce the reference of old gen to ygc gen and reduce the cost of remark. Generally, 80% of the GC of CMS is in the remark phase.) to avoid full gc caused by Perm full, it is recommended to enable CMS recycling Perm area option: + CMSPermGenSweepingEnabled-XX:+CMSClassUnloadingEnabled-XX:+UseConcMarkSweepGC: set the old generation to concurrent collection. After configuring this in the test, the configuration of-XX:NewRatio=4 failed for an unknown reason. Therefore, at this time, the size of the younger generation is best set with-Xmn. -XX:+UseParNewGC: set the younger generation to collect in parallel. Can be used in conjunction with CMS collection. Above JDK5.0, JVM will be set according to the system configuration, so it is no longer necessary to set this value.

G1 collector

Collector combination switch option-XX:+UseSerialGC Serial+SerialOld-XX:+UseParNewGC ParNew+SerialOld-XX:+UseParallelGC ParallelScavenge+SerialOld-XX:+UseConcMarkSweepGC ParNew+CMS+SerialOld FullGC algorithm: single-threaded MarkSweep Compact (MSC)-XX:+UseParallelOldGC ParallelScavenge+Parallel Old FullGC algorithm: PS MarkSweepJVM parameter garbage collection parameter-whether Xnoclassgc collects the class-verbose:class-XX:+TraceClassUnloading view class load and unload information-ratio of XX:SurvivorRatio Eden to one of the survivor-threshold for XX:PretenureSizeThreshold large objects entering the old age Effective of Serial and ParNew-the age of the object promoted by XX:MaxTenuringThreshold is 15 by default, and CMS is guaranteed by 4-XX:HandlePromotionFailure by default-XX:+UseAdaptiveSizePolicy dynamically adjusts the size of each area in the Java heap and the number of threads reclaimed in parallel by XX:ParallelGCThreads-XX:MaxGCPauseMillis Parallel Scavenge parameter, sets the maximum pause time of GC-XX:GCTimeRatio Parallel Scavenge parameter, the ratio of GC time to total time, and defaults 99%, that is, 1% GC time-XX:CMSInitiatingOccupancyFraction Old region triggers cms threshold. Default 68%-XX:+UseCMSCompactAtFullCollection (whether to defragment once after CMS is completed, pause time is longer)-XX:CMSFullGCsBeforeCompaction (how many times to perform non-defragmented FullGC and once with compression)-XX:+ScavengeBeforeFullGC Trigger minorGC garbage collection statistics before fullgc-XX:+PrintGC output GC log-verbose:gc is equal to the detailed log heap size setting of the above-XX:+PrintGCDetails output GC-Xmx: maximum heap size-Xms: initial heap size (minimum memory value)-Xmn: young generation size-XX:NewSize and-XX:MaxNewSize Cenozoic size-XX:SurvivorRatio:3 means the ratio of Eden to two Survivor regions in the younger generation. Notice that there are two in the Survivor area. For example, 3, indicates Eden:Survivor=3:2, the 1/5-XX:NewRatio=4 of which one Survivor area accounts for the entire younger generation: sets the ratio of the younger generation (including Eden and two Survivor zones) to the older generation (excluding the persistent generation). Set to 4, the ratio of the younger generation to the older generation is 1:4, and the 1/5-Xss stack capacity of the younger generation accounts for the whole stack default 256k-XX:PermSize permanent generation initial value-XX:MaxPermSize permanent generation maximum value

Production environment parameter configuration (CMS-GC)

Java

< 8 -server -Xms[g|m|k] -Xmx[g|m|k] -XX:PermSize=[g|m|k] -XX:MaxPermSize=[g|m|k] -Xmn[g|m|k] -XX:+DisableExplicitGC -XX:SurvivorRatio= -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction= -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"" -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=`date`.hprof -Dsun.net.inetaddr.ttl= -Djava.rmi.server.hostname= -Dcom.sun.management.jmxremote.port= -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=falseJava >

= 8-server-XX:SurvivorRatio= [g | m | k]-Xmx [g | m | k]-XX:MaxMetaspaceSize= [g | m | k]-Xmn [g | m | k]-XX:+DisableExplicitGC-XX:SurvivorRatio=-XX:+UseConcMarkSweepGC-XX:+CMSParallelRemarkEnabled-XX:+CMSScavengeBeforeRemark-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=-XX:+PrintGCDateStamps-verbose:gc-XX:+PrintGCDetails-Xloggc: ""-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=10-XX:GCLogFileSize=100M-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath= `date` .hprof-Dsun.net.inetaddr.ttl=-Djava.rmi.server.hostname=-Dcom.sun.management.jmxremote.port=-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false understands the new generation name of GC log DefNew:Serial collector-Tenured-PermParNew:ParNew collector new generation name-PSYoungGen:Parallel Scavenge collector new generation name JVM tuning

GC's time is small enough.

The number of GC is small enough.

The period in which Full GC occurs is long enough.

The first two are currently contrary to each other. For GC time to be small, we must have a smaller heap. To ensure that the number of GC is small enough, we must ensure a larger heap, which we can only balance.

(1) for the setting of JVM heap, the minimum and maximum values can be defined by-Xms-Xmx. In order to prevent the garbage collector from shrinking the heap between the minimum and maximum, we usually set the maximum and minimum to the same value.

(2) the younger generation and the older generation will allocate heap memory according to the default ratio (1:2). You can adjust the size between them by adjusting the ratio NewRadio, or for the recycled generation, for example, the younger generation, use-XX:newSize-XX:MaxNewSize to set its absolute size. Similarly, to prevent the heap of the younger generation from shrinking, we usually set the-XX:newSize-XX:MaxNewSize to the same size. -XX:PermSize,-XX:MaxPermSize is set to the same to prevent old age from shrinking. -XX:NewRatio=4: sets the ratio of the younger generation (including Eden and two Survivor zones) to the older generation (excluding the persistent generation). Set to 4, the ratio of the younger generation to the older generation is 1:4, and the younger generation accounts for 1 XX:MaxTenuringThreshold=0 of the entire stack: sets the maximum age of garbage. If set to 0, the younger generation will enter the older generation without going through the Survivor area. For more applications of the older generation, it can improve the efficiency. If you set this value to a large value, the younger generation object will be replicated multiple times in the Survivor area, which can increase the survival time of the younger generation of the object and increase the overview of being recycled in the younger generation.

(3) how big is the setting for the younger generation and the older generation? There is no doubt that there is no answer to this question, otherwise there would be no tuning. Let's take a look at how the size changes affect the setting of the younger generation and the older generation: the entire JVM memory size = the younger generation size + the older generation size + the persistent generation size. The permanent generation usually has a fixed size of 64m, so increasing the size of the younger generation will reduce the size of the old generation. This value has a great impact on system performance, and the Sun officially recommends that the younger generation be configured as 3 Universe 8 of the entire heap.

The younger generation will inevitably lead to the younger generation, the older generation will prolong the cycle of the normal GC, but will increase the time of each GC; the younger generation will lead to more frequent Full GC.

The younger generation will inevitably lead to the older generation, the younger generation will cause the ordinary GC to be very frequent, but each time the GC time will be shorter; the older generation will reduce the frequency of Full GC.

How to choose should depend on the distribution of the life cycle of application objects: if there are a large number of temporary objects in the application, you should choose a larger younger generation; if there are relatively more persistent objects, the older generation should increase appropriately. However, many applications do not have such obvious characteristics, so the choice should be based on the following two points: (a) in line with the principle of minimizing Full GC, let the older generation cache commonly used objects as much as possible, and the default ratio of JVM is 1:2. (B) by observing the application for a period of time, see how much memory other older generations will occupy at the peak, and increase the younger generation according to the actual situation without affecting Full GC. For example, the ratio can be controlled at 1:1. But the older generation should be given at least 1 prime 3 room for growth.

(4) on well-configured machines (such as multi-cores and large memory), you can choose a parallel collection algorithm for the elderly:-XX:+UseParallelOldGC. The default is Serial collection.

(5) setting of thread stack: each thread opens a 1m stack by default, which is used to store stack frames, call parameters, local variables, etc. For most applications, this default value is too much. 256k is generally sufficient. In theory, reducing the stack of each thread can result in more threads with the same memory, but this is actually limited by the operating system. -Xss256k: sets the stack size for each thread. The stack size of each thread after JDK5.0 is 1m, and the stack size of each thread before is 256K. Adjust the amount of memory required by more applicable threads. Decreasing this value generates more threads under the same physical memory. However, the operating system still has a limit on the number of threads in a process, which cannot be generated indefinitely, and the experience value is about 3000 to 5000.

(6) you can type Heap Dump information with the following parameters

-XX:HeapDumpPath-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:/usr/aaa/dump/heap_trace.txt controls the information of the print heap during OutOfMemoryError through the following parameters-XX:+HeapDumpOnOutOfMemoryError

Note: through the analysis of dump files, it can be found that Full GC occurs every hour. After multi-party verification, as long as the JMX service is turned on in JVM, JMX will execute Full GC once an hour to clear references.

Performance analysis tool

Jps

-m parameter of the main class-l full name of the main class. If the jar package is executed, output the jar path-v virtual machine parameter

Jstat

Monitor virtual machine running status information, including class loading, GC, run-time compilation (JIT) to output java program memory usage Including the new generation, the old age, the capacity of the metadata area, Garbage collection jstat-gcutil 52670 2000 5 process number 2s output a total of 5 times S0: survival Zone 1 current use ratio S1: survival Zone 2 current use ratio E: Eden Park usage ratio O: old age usage ratio M: metadata area usage ratio CCS: compression usage ratio YGC: young generation garbage collection times YGCT: young generation garbage collection time FGC: old generation garbage collection times FGCT: garbage recovery time in the old years GCT: total garbage collection time

Jmap

Jmap: used to generate heap dump snapshots. Commonly referred to as dump or heapdump files. Jmap-histo 3618 the above command prints out the memory of the process with an ID of 3618, including what objects there are and the number of objects. However, our common method is to output the memory heap of the specified process to an external file, and then analyze it by a special heap analysis tool, such as mat (Memory Analysis Tool), so our common command is: jmap-dump:live,format=b,file=heap.hprof 3618M F forces the generation of dump snapshots.

Jstack

Jstack: the user outputs a thread snapshot of the current moment of the virtual machine, which is often used to locate failures or performance problems caused by certain thread problems. Commonly referred to as threaddump files. Parameter-F forces stack information to be printed when the normal output does not respond. In general, it is not necessary to use-l long list. Print additional information about the lock. In general, you do not need to use-m. If the local method is called, you can print the stack of cAccord cymbal +.

Jinfo

View and modify virtual machine parameters

Visual tool JConsole Java Monitoring and Management console VisualVM all-in-one Fault handling tool

Java Class file type prefix

Element Type Encodingboolean Zbyte Bchar Cdouble Dfloat Fint Ilong Jshort S class or interface Lclassname; [L] represents the layer memory leak of the corresponding type array nesting and its solution.

1. Some phenomena before the system crash:

The time of each garbage collection is longer and longer, from the previous 10ms to about 50ms, and the FullGC time is also extended from 0.5s to 4,5s.

The frequency of FullGC is increasing, and the most frequent FullGC is carried out at intervals of less than 1 minute.

The memory of the older generation is getting larger and larger, and no memory is released every time the FullGC is followed by the older generation.

After that, the system will not be able to respond to new requests and gradually reach the critical value of OutOfMemoryError.

two。 The dump file that generates the heap generates the current Heap information through the MBean of JMX, which is a 3G (the size of the entire heap) hprof file. If you do not start JMX, you can generate this file through the jmap command of Java.

3. Analyze dump files

The next thing to consider is how to open the 3G heap information file. Obviously, ordinary Window systems do not have such a large amount of memory and must rely on high-configuration Linux. Of course, we can import graphics from Linux into Window with the help of X-Window. We consider opening the file with the following tools:

Hprof tools that come with 1.Visual VM 2.IBM HeapAnalyzer 3.JDK

To ensure loading speed when using these tools, it is recommended that you set the maximum memory to 6G. After use, it is found that these tools can not directly observe memory leaks, Visual VM can observe the object size, but can not see the call stack; although HeapAnalyzer can see the call stack, it can not correctly open a 3G file. Therefore, we choose Eclipse's special static memory analysis tool: Mat.

4. Analyze memory leaks

Through Mat, we can clearly see which objects are suspected of memory leaks, which objects take up the largest amount of space, and the object invocation relationship. In view of this case, there are many instances of JbpmContext in ThreadLocal. After investigation, the Context of JBPM is not closed.

In addition, through Mat or JMX, we can analyze the thread state and observe which object the thread is blocked on, so as to determine the bottleneck of the system.

5. Regression problem

Q: why does garbage collection take longer and longer before the crash?

A: according to the memory model and garbage collection algorithm, garbage collection is divided into two parts: memory marking, clearing (copying). As long as the memory size of the mark part is fixed, the time is constant, and the copy part changes. Because each garbage collection has some unrecyclable memory, so the amount of replication is increased, resulting in a longer time. Therefore, the time of garbage collection can also be used as a basis for judging memory leaks.

Q: why are there more and more Full GC?

A: as a result, the accumulation of memory gradually depletes the memory of the older generation, resulting in no more space for new object allocation, resulting in frequent garbage collection

Q: why is the older generation taking up more and more memory?

A: because the memory of the younger generation cannot be reclaimed, it is increasingly being Copy to the older generation.

Tuning method

Everything is for this step, tuning, before tuning, we need to remember the following principles:

1. Most Java applications do not need GC optimization on the server.

2. Most Java applications that cause GC problems are not because of our wrong parameter settings, but because of code problems.

3. Before launching the application, consider setting the JVM parameters of the machine to the optimal (most suitable)

4. Reduce the number of objects created

5. Reduce the use of global variables and large objects

6. GC optimization is a last resort.

7. In practice, analyzing the GC situation and optimizing the code is much more than optimizing the GC parameters.

There are two purposes of GC optimization

1. Minimize the number of objects transferred to the old era

2. Reduce the execution time of full GC

In order to achieve the above goals, in general, what you need to do are:

1. Reduce the use of global variables and large objects

2. Adjust the size of the new generation to the most appropriate

3. Set the size of the old age to be the most appropriate

4. Select the appropriate GC collector

Thank you for your reading, the above is the content of "introduction of Java garbage collector and JVM tuning method". After the study of this article, I believe you have a deeper understanding of the introduction of Java garbage collector and JVM tuning method, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.