Objective
After getting started with the JVM garbage collection mechanism, you can then learn the performance tuning. There are two main parts of the content:
- The use of JDK tools.
- Tuning strategy.
Weapon Spectrum JPS
List the running virtual machine processes, using the following:
JPS [-option] [HostID]
Options |
function |
Q |
Output only Lvmid, omit the name of the main class |
M |
Output the parameters of Main method |
L |
Output the full package name, apply the main class name, the full path name of the jar |
V |
Output JVM Parameters |
Jstat
To monitor the virtual machine health status information, how to use:
Jstat-<option> <pid> [Interval[s|ms]
Options |
function |
Gc |
The amount of time that the GC operation accumulates, the total number of times that the GC has been performed, and the amount of space that is currently available for each heap area. |
Gccapactiy |
Outputs the minimum space limit (MS)/Maximum space limit (MX) for each heap area, the current size, and the number of times the GC is executed on top of each zone. (The current used space is not output and the GC execution time). |
Gccause |
Outputs the information provided by-gcutil and why the GC was last executed and the reason for the GC that is currently executing. |
Gcnew |
The GC performance data for the output generation space. |
Gcnewcapacity |
Statistics on the size of the output Cenozoic space. |
Gcold |
Output GC performance data for the old age space. |
Gcoldcapacity |
Output statistics of the size of the old age space. |
Gcpermcapacity |
Statistics that output the size of the persistent space. |
Gcutil |
Outputs the usage ratio for each heap area, as well as the total number of GC executions and events spent by GC operations. |
Like what:
JSTAT-GC 28389 1s
Output JVM Runtime information every 1 seconds:
s0c s1c s0u s1u EC EU OC OU PC PU ygc ygct FGC FGCT GCT 52416.0 52416.0 4744.9 0.0 419456.0 28180.6 2621440.0 439372.6 131072.0 33564.8 160472 1760.603 2.731 1763.334
column |
Description |
jstat Parameters |
s0c |
The size of the Survivor0 space. Unit KB. |
-gc-gccapacity-gcnew-gcnewcapacity |
S1c |
The size of the Survivor1 space. Unit KB. |
-gc-gccapacity-gcnew-gcnewcapacity |
s0u |
Survivor0 the size of the space already used. Unit KB. |
-gc-gcnew |
s1u |
Survivor1 the size of the space already used. Unit KB. |
-gc-gcnew |
EC |
The size of the Eden space. Unit KB. |
-gc-gccapacity-gcnew-gcnewcapacity |
EU |
The size of Eden used space. Unit KB. |
-gc-gcnew |
Oc |
The size of the old age space. Unit KB. |
-gc-gccapacity-gcold-gcoldcapacity |
OU |
The old age has used the size of space. Unit KB. |
-gc-gcold |
Pc |
The size of the persistent generation space. Unit KB. |
-gc-gccapacity-gcold-gcoldcapacity-gcpermcapacity |
Pu |
The size of the space that is used for persistent generations. Unit KB. |
-gc-gcold |
Ygc |
The number of times the generation of space GC time occurred. |
-gc-gccapacity-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause |
Ygct |
The time taken by the new generation of GC processing. |
-gc-gcnew-gcutil-gccause |
FGC |
The number of times the full GC occurred. |
-gc-gccapacity-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause |
Fgct |
The time spent by the full GC operation. |
-gc-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause |
GCT |
Total time spent by GC operations. |
-gc-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause |
Ngcmn |
Cenozoic minimum space capacity, in kilobytes. |
-gccapacity-gcnewcapacity |
Ngcmx |
Maximum space capacity in the Cenozoic, in kilobytes. |
-gccapacity-gcnewcapacity |
Ngc |
Current space capacity in the new generation, in kilobytes. |
-gccapacity-gcnewcapacity |
Ogcmn |
The minimum space capacity in the old age, in kilobytes. |
-gccapacity-gcoldcapacity |
Ogcmx |
The maximum space capacity in the old age, in kilobytes. |
-gccapacity-gcoldcapacity |
OGC |
The current space capacity system in the old age, in kilobytes. |
-gccapacity-gcoldcapacity |
Pgcmn |
The minimum space capacity of a persistent generation, in kilobytes. |
-gccapacity-gcpermcapacity |
Pgcmx |
The maximum space capacity, in kilobytes, for a persistent generation. |
-gccapacity-gcpermcapacity |
Pgc |
The current space capacity, in kilobytes, for the persistent generation. |
-gccapacity-gcpermcapacity |
Pc |
The current space size, in kilobytes, of the persistent generation. |
-gccapacity-gcpermcapacity |
Pu |
The current space size, in kilobytes, of the persistent generation. |
-gc-gcold |
lgcc |
The reason for the last GC to occur. |
-gccause |
Gcc |
The reason for the current GC to occur. |
-gccause |
Tt |
The threshold of aging. The number of empty lives in the Cenozoic before being moved to the old age. |
-gcnew |
Mtt |
Maximum age threshold. The number of empty lives in the Cenozoic before being moved to the old age. |
-gcnew |
Dss |
The amount of space required for the survivor area, in kilobytes. |
-gcnew |
Jmap
Heap storage snapshots, using:
Jmap [-option] <pid>
Options |
function |
Dump |
A heap of storage snapshots in the format:-dump:[live,]format=b, file=<filename>,live indicates whether to dump only the surviving objects. |
Heap |
Displays Java heap details, such as the use of that collector, parameter configuration, generational status, and so on. |
Histo |
Displays the object statistics in the heap, including the class, number of instances, and total capacity. |
Jstack
Generates a thread snapshot of the current moment of the virtual machine, helping to locate the cause of the thread's long pause, using:
Jstack <pid>
Monitor
Monitor is the primary means of using Java to achieve mutual exclusion and collaboration between threads, which can be seen as an object or class lock. Every object has, and only one monitor. The following diagram depicts the relationship between the thread and monitor, and the state transition diagram of the thread:
Entry Zone (ENTRT Set): Indicates that the thread acquires the lock of the object through synchronized requirements, but does not get it.
Owner (the owner): indicates that the thread successfully competed to the object lock.
Wait Set: Indicates that the thread passes the object's Wait method, frees the object's lock, and waits in the wait area to be awakened.
Thread state
- NEW, not started. does not appear in dump.
- RUNNABLE, executed within the virtual machine.
- BLOCKED, wait for the monitor lock.
- Wating, waits indefinitely for another thread to perform a specific operation.
- Timed_wating, a time-bound wait for a specific operation on another thread.
- TERMINATED, has exited.
As an example:
package Com.jiuyan.mountain.test;import java.util.concurrent.timeunit;/*** Hello world!* */public class App {public static void main (string[] args) throws Int erruptedexception {mytask task = new MyTask (); thread T1 = new thread (Task); T1.setname ("T1"); Thread t2 = new Thread (Task); T2.setname ("T2"); T1.start (); T2.start (); }}class MyTask implements Runnable {private Integer mutex; Public MyTask () {mutex = 1; } @Override public void Run () {synchronized (mutex) {while (true) {System.out.pri Ntln (Thread.CurrentThread (). GetName ()); try {TimeUnit.SECONDS.sleep (5); } catch (Interruptedexception e) {//TODO auto-generated catch block e.printstacktr Ace (); } } } }}
Thread State:
"T2" prio=10 tid=0x00007f7b2013a800 NID=0X67FB waiting for monitor entry [0x00007f7b17087000]java.lang.thread.state: BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:35) – Waiting to lock <0X00000007D6B6DDB8 > (a Java.lang.Integer) at Java.lang.Thread.run (thread.java:745) "T1" prio=10 tid=0x00007f7b20139000 NID=0X67FA Waiting on condition [0x00007f7b17188000]java.lang.thread.state:timed_waiting (sleeping) at Java.lang.Thread.sleep ( Native Method)
T1 did not grab the lock, so the display BLOCKED. T2 grabbed the lock, but was in sleep, so show timed_waiting, limited wait for a certain condition to wake up.
Remove the sleep code and the thread state becomes:
"T2" prio=10 tid=0x00007fa0a8102800 nid=0x6a15 waiting for monitor entry [0x00007fa09e37a000]java.lang.thread.state: BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:35) – Waiting to lock <0x0000000784206650 > (a Java.lang.Integer) at Java.lang.Thread.run (thread.java:745) "T1" prio=10 tid=0x00007fa0a8101000 nid=0x6a14 runnable [0x00007fa09e47b000]java.lang.thread.state:runnable at Java.io.FileOutputStream.writeBytes (Native Method)
T1 display RUNNABLE, instructions are running, here is an additional explanation, if this thread is querying the database, but the database deadlock, although the thread appears to be running, and actually does not work, for the IO-type thread only use the thread state to determine whether the work is normal.
Change the MyTask code a little bit, the thread gets the lock, executes wait, releases the lock, and enters the waiting area.
public void Run () { synchronized (mutex) { if (mutex = = 1) { try { mutex.wait (); } catch (Interruptede Xception e) { //TODO auto-generated catch block e.printstacktrace (); } } }
The thread status is as follows:
"T2" prio=10 tid=0x00007fc5a8112800 nid=0x5a58 in object.wait () [0x00007fc59b58c000]java.lang.thread.state:waiting ( on object monitor) at java.lang.Object.wait (Native Method) "T1" prio=10 tid=0x00007fc5a8111000 nid=0x5a57 in Object.wait ( ) [0x00007fc59b68d000]java.lang.thread.state:waiting (on Object monitor) at java.lang.Object.wait (Native Method)
Two threads all display waiting, this time is indefinite, need to regain the lock, so followed by on object Monitor.
Another example of a deadlock:
Package Com.jiuyan.mountain.test;import java.util.concurrent.timeunit;/*** Hello world!* */public class App {public S tatic void Main (string[] args) throws Interruptedexception {MyTask Task1 = new MyTask (true); MyTask Task2 = new MyTask (false); thread T1 = new Thread (TASK1); T1.setname ("T1"); Thread t2 = new Thread (TASK2); T2.setname ("T2"); T1.start (); T2.start (); }}class MyTask implements Runnable {private Boolean flag; Public MyTask (Boolean flag) {This.flag = flag; } @Override public void Run () {if (flag) {synchronized (MUTEX.MUTEX1) { try {TimeUnit.SECONDS.sleep (1); } catch (Interruptedexception e) {//TODO auto-generated catch block E.printstacktrace (); } SynchronizEd (mutex.mutex2) {System.out.println ("OK"); }}} else {synchronized (MUTEX.MUTEX2) {try { TimeUnit.SECONDS.sleep (1); } catch (Interruptedexception e) {//TODO auto-generated catch block E.printstacktrace (); } synchronized (MUTEX.MUTEX1) {System.out.println ("OK"); }}}}}class Mutex {public static Integer mutex1 = 1; public static Integer mutex2 = 2;}
Thread Status:
"T2" prio=10 tid=0x00007f5f9c122800 nid=0x3874 waiting for monitor entry [0x00007f5f67efd000]java.lang.thread.state: BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:55) – Waiting to lock <0x00000007d6c45bd8 > (a java.lang.Integer)-locked <0x00000007d6c45be8> (a Java.lang.Integer) at Java.lang.Thread.run ( thread.java:745) "T1" prio=10 tid=0x00007f5f9c121000 nid=0x3873 waiting for monitor entry [0x00007f5f67ffe000] Java.lang.Thread.State:BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:43) – Waiting to Lock <0x00000007d6c45be8> (a java.lang.Integer)-locked <0x00000007d6c45bd8> (a java.lang.Integer) at Java.lang.Thread.run (thread.java:745) Found one java-level deadlock:============================= "T2": Waiting to Lock monitor 0x00007f5f780062c8 (Object 0x00000007d6c45bd8, a Java.lang.Integer), which is held by "T1" "T1": Waiting to lock Monitor 0x00007f5f78004ed8 (Object 0x00000007d6c45be8, a java.lang.Integer), WHIch is held by "T2"
It's kind of like a philosopher's meal, and each thread holds the lock the other person needs, and that's not going to work.
Two basic principles of tuning Strategy:
- The number of objects to be transferred to the old age is minimized.
- Reduce the execution time of full GC. The goal is to minor GC time within 100MS and full gc time within 1s.
Main tuning Parameters:
Set the heap memory size, which is the most basic.
- -XMS: Heap memory space When the JVM is started.
- -XMX: Maximum heap memory limit.
Sets the Cenozoic size.
The new generation should not be too small, otherwise there will be a large number of objects pouring into the old age.
- -xx:newratio: The proportion of the new generation and the old age.
- -xx:newsize: Cenozoic space.
- -xx:survivorratio: The proportion of Eden space and survivor space.
- -xx:maxtenuringthreshold: Age threshold for objects entering the old age.
Setting up the garbage collector
Young generation:-XX:+USEPARNEWGC.
Old age:-XX:+USECONCMARKSWEEPGC.
CMS can minimize STW time, but does not compress memory, there is a possibility of "parallel mode failure". For example, the old age space has 300MB space, but some 10MB objects cannot be stored sequentially. Compression processing is triggered, but the compression processing time in CMS GC mode is much longer than the parallel GC.
G1 uses the "mark-and-organize" algorithm to solve the memory fragmentation problem and establish a predictable pause-time type, which allows the user to specify a time period of M milliseconds to consume less than n milliseconds for garbage collection.
JVM Performance Tuning Getting Started Guide