5-commands commonly used by JVM

Commands commonly used by JVM jps...
jps: basic tools
jinfo: commands can be used to view the JVM parameters of the Java process
jstat: mainly for real-time command-line monitoring of java application resources and performance, including monitoring of heap size and garbage collection status
jstack: View thread stack information in a Java process
Jmap
Commands commonly used by JVM

jps: basic tools

View the JAVA process PID.

The jps command is used to view all Java processes. Each line is a java process information.

jps only looks up the Java processes of the current user, not all processes in the current system. To display other users, it can only use the ps command.

jps common parameters

  • If jps-l is running in class mode, it will display the full name of main.class, the main class of the process. If it is running in jar package mode, it will output the full path name of jar package

The number in the first column is the pid of the process

  • Jps-v outputs the parameters passed to the JVM, V represents the virtual machine, and jps-vl is a common combination;
  • jps -V capital v, which represents the parameters passed to the JVM through a file
Copy# michael @ Michael-MBP in ~ [16:37:59] $ jps -v |grep Mybatis 8005 MybatisDemoApplication -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:53364,suspend=y,server=n -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=53363 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=127.0.0.1 -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -javaagent:/Users/michael/Library/Caches/IntelliJIdea2018.2/captureAgent/debugger-agent.jar=file:/private/var/folders/m1/ydypchs901lffc5sms07mrp40000gn/T/capture.props -Dfile.encoding=UTF-8
  • Jps-m outputs the parameters passed to the main.class method. It is a practical command. Jps-ml is a more practical combination. The package name / class name / parameter will be displayed
  • Jps-q only outputs pid of process

jps is a common Java command. Use jps to see which Java processes are currently running. If you run a web application (start with tomcat, jboss, jetty, etc.), you can use jps to view the startup.

Sometimes I want to know where the log of this application will be output, or which Java agent is used when starting, then I can use jps-v to view the jvm parameters of the process.

jinfo: commands can be used to view the JVM parameters of the Java process

Refer to the original text: https://blog.csdn.net/yx0628/article/details/80958488

jinfo -flag initilHeapSize $ looks at the parameter value of the JVM in a JAVA process.

jinfo -flag $ if the JVM parameter is not added, all modified values in the JVM will be viewed by default.

[root@admin ~]# jinfo --help Usage: jinfo [option] <pid> (to connect to running process) jinfo [option] <executable <core> (to connect to a core file) jinfo [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server) where <option> is one of: -flag <name> to print the value of the named VM flag -flag [+|-]<name> to enable or disable the named VM flag -flag <name>=<value> to set the named VM flag to the given value -flags to print VM flags -sysprops to print Java system properties <no option> to print both of the above -h | -help to print this help message

First, we use the jps command to find the PID, and then we can view the parameter information of the corresponding process through jinfo:

[root@admin ~]# jps 43520 Test 35900 Jps

To view JVM parameters:

[root@admin ~]# jinfo -flags 43520 Attaching to process ID 43520, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24.45-b08 -Dfile.encoding=GBK

To view system parameters:

[root@admin ~]# jinfo -sysflags 43520

The parameters of the virtual machine can be viewed through this command:

java -XX:+PrintFlagsFinal -version | grep manageable

In addition to setting parameters through the startup script, PrintGC is on by default, so we only need to open the PrintGCDetails parameter.

jinfo -flag +PrintGC 43520 jinfo -flag +PrintGCDetails 43520

The same is true for closing GC logs:

jinfo -flag -PrintGC 43520 jinfo -flag -PrintGCDetails 43520

To see whether to turn on printing of GC logs:

jinfo -flag PrintGC 43520 jinfo -flag PrintGCDetails 43520
[root@admin ~]# jinfo -flag PrintGC 43520 -XX:-PrintGC [root@admin ~]# jinfo -flag PrintGCDetails 43520 -XX:-PrintGCDetails

Common JVM parameters:

-Xms: initial heap size, default to 1 / 64 of physical memory (< 1GB); default (MinHeapFreeRatio parameter can be adjusted) when the free heap memory is less than 40%, the JVM will increase the heap until the maximum limit of - Xmx -Xmx: maximum heap size. By default (MaxHeapFreeRatio parameter can be adjusted), when the free heap memory is greater than 70%, the JVM will reduce the heap to the minimum limit of - Xms -Xmn: the memory space size of the new generation, note: the size here is (eden+ 2 survivor space). It is different from the New gen shown in jmap heap. The whole heap size = Cenozoic size + old generation size + permanent generation size. Under the condition of keeping the heap size constant, increasing the Cenozoic will reduce the size of the old generation. This value has a great impact on the system performance. Sun officially recommends that the configuration be 3 / 8 of the whole heap. -20: Survivorratio: the capacity ratio of Eden area to Survivor area in Cenozoic, the default value is 8. The ratio of two Survivor regions to one Eden region is 2:8, and one Survivor region accounts for 1 / 10 of the whole young generation. -Xss: stack size per thread. After JDK 5.0, the stack size of each thread is 1M, and before, the stack size of each thread is 256K. It should be adjusted according to the memory size required by the application thread. In the same physical memory, reducing this value can generate more threads. However, the operating system has a limit on the number of threads in a process, which can not be generated infinitely. The experience value is about 3000-5000. For small applications, if the stack is not very deep, it should be 128k. For large applications, 256K is recommended. This option has a large impact on performance and requires strict testing. Similar to the interpretation of threadstacksize option, it seems that the official document does not explain it. There is a sentence in the Forum: "Xss is translated in a VM flag named ThreadStackSize" generally, you can set this value. -20: PermSize: set the initial value of perm Gen. The default is 1 / 64 of physical memory -20: Maxpermsize: sets the persistent generation maximum. 1 / 4 of physical memory.

jstat: mainly for real-time command-line monitoring of java application resources and performance, including monitoring of heap size and garbage collection status

Original reference: https://blog.csdn.net/cockroach02/article/details/82670500

View information about performance in the JVM.

jstat (Java Virtual Machine Statistics Monitoring Tool) is a lightweight gadget from JDK 1.5. It is located in the java/bin directory. It mainly uses the instructions built in the JVM to monitor the resources and performance of the Java virtual machine in real time.

Class loading information: jstat -class $

For example: jstat -class $ $ $ = jstat -class $ 1000 10. Print out the data loaded by the class in the past 10 seconds.

GC related situation: jstat -gc $

For example: jstat -gc $ $ $ = jstat -gc $ 1000 10. Print out the data of GC in the past 10 seconds.

Parameter Description:

C:\Users\Administrator>jstat -help Usage: jstat -help|-options jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] Definitions: <option> An option reported by the -options option <vmid> Virtual Machine Identifier. A vmid takes the following form: <lvmid>[@<hostname>[:<port>]] Where <lvmid> is the local vm identifier for the target Java virtual machine, typically a process id; <hostname> is the name of the host running the target Java virtual machine; and <port> is the port number for the rmiregistry on the target host. See the jvmstat documentation for a more complete description of the Virtual Machine Identifier. <lines> Number of samples between header lines. <interval> Sampling interval. The following forms are allowed: <n>["ms"|"s"] Where <n> is an integer and the suffix specifies the units as milliseconds("ms") or seconds("s"). The default units are "ms". <count> Number of samples to take before terminating. -J<flag> Pass <flag> directly to the runtime system.

From the above, the format of jstat command is as follows:

jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

We can view the specific parameters that can be supported through jstat -options

C:\Users\Administrator>jstat -options -class -compiler -gc -gccapacity -gccause -gcmetacapacity -gcnew -gcnewcapacity -gcold -gcoldcapacity -gcutil -printcompilation

Option Parameter Description:

parameter explain -class Displays statistics about the behavior of the class loader -compiler Displays statistics about the behavior of the Java hotspot VM just in time compiler -gc Behavior statistics of garbage collection heap. Displays statistics about the behavior of the garbage collected heap. -gccapacity Each garbage collection generation capacity (young,old,meta) and their corresponding spatial statistics. isplays statistics about the capacities of the generations and their corresponding spaces. -gccause Garbage collection statistics overview (the same as - gcutil), with reasons for the last two garbage collection events attached. Displays a summary about garbage collection statistics (same as -gcutil), with the cause of the last and current (when applicable) garbage collection events. -gcmetacapacity Displays statistics about the sizes of the metadata -gcnew Displays statistics of the behavior of the new generation -gcnewcapacity Displays statistics about the sizes of the new generations and its corresponding spaces -gcold Displays statistics about the behavior of the old generation and metadata statistics -gcoldcapacity Displays statistics about the sizes of the old generation -gcutil Displays a summary about garbage collection statistics -printcompilation Displays Java HotSpot VM compilation method statistics

Use example:

Jstat class: behavior statistics of class loading

C:\Users\Administrator>jstat -class 2284 Loaded Bytes Unloaded Bytes Time 30116 75021.8 26 51.4 86.72
  • Loaded: number of loaded class es
  • Bytes: size of the loaded class in kilobytes
  • Unloaded: number of unloaded class es
  • Bytes: size of the unload class in kilobytes
  • Time: time spent loading and unloading class es

jstat -compiler: hotspot JIT compiler behavior statistics

C:\Users\Administrator>jstat -compiler 2284 Compiled Failed Invalid Time FailedType FailedMethod 21247 8 0 189.38 1 com/fr/third/alibaba/druid/pool/DruidDataSource shrink
  • Compiled: number of compilation success
  • Failed: number of compilation failures
  • Invalid: invalid quantity
  • FailedType: last compilation failure type
  • Failed method: the method failed in the last compilation

Jstat GC: behavior statistics of garbage collection heap

C:\Users\Administrator>jstat -gc 2284 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 104832.0 104832.0 0.0 0.0 838912.0 600103.2 1048576.0 565828.4 238672.0 232272.3 22392.0 21028.5 59 4.898 11 6.323 11.221
  • S0C: total capacity of the first surviving area (KB)
  • S1C: total capacity of the second surviving area (KB)
  • S0U: used capacity of the first survivor (KB)
  • S1U: used capacity of the second surviving area (KB)
  • EC: total capacity of Eden (KB)
  • EU: used capacity of Eden (KB)
  • OC: total capacity of elderly area (KB)
  • MC: total capacity of meta space (KB)
  • MU: used capacity of meta space (KB)
  • CCSC: total capacity of compressed class space (KB)
  • CCSU: total used capacity of compressed class space (KB)
  • YGC: number of new generation GC
  • YGCT: total time consumption of new generation GC
  • FGC: number of GC in the elderly
  • FGCT: the total time consumption of GC in the elderly
  • GCT: total GC time

jstat -gccapacity: memory of each recycle area

C:\Users\Administrator>jstat -gccapacity 2284 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1048576.0 1048576.0 1048576.0 104832.0 104832.0 838912.0 1048576.0 3145728.0 1048576.0 1048576.0 0.0 1265664.0 238672.0 0.0 1048576.0 22392.0 59 11
  • NGCMN: the minimum space size occupied by the new generation (KB)
  • NGCMX: the maximum space size occupied by the new generation (KB)
  • NGC: current Cenozoic space size (KB)
  • S0C: current space size of the first survivor (KB)
  • S1C: current space size of the second survival area (KB)
  • EC: current space size of Eden (KB)
  • OGCMN: minimum space size of elderly area (KB)
  • OGCMX: maximum space size of elderly area (KB)
  • OGC: current space size of elderly area (KB)
  • MCMN: minimum space size of meta space (KB)
  • MCMX: maximum size of meta space (KB)
  • MC: current space size of meta space (KB)
  • CCSMN: minimum size of compressed class space (KB)
  • CCSMX: maximum space size of compression class (KB)
  • CCSC: current space size of compression class (KB)
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly

jstat -gccause: an overview of garbage collection statistics

C:\Users\Administrator>jstat -gccause 2284 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 0.00 0.00 91.90 53.96 97.32 93.91 59 4.898 11 6.323 11.221 System.gc() No GC
  • S0: percentage of space used in the first surviving area
  • S1: percentage of space used in the second surviving area
  • E: Percentage of space used in Eden
  • O: Percentage of space used in the elderly
  • M: Percentage of meta space used
  • CCS: compressed space usage percentage
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly
  • LGCC: last GC reason
  • GCC: current GC reason

6. GC - gcmetacapacity: Metaspace usage

C:\Users\Administrator>jstat -gcmetacapacity 2284 MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC FGCT GCT 0.0 1265664.0 238672.0 0.0 1048576.0 22392.0 59 11 6.323 11.221
  • MCMN: minimum space size of meta space (KB)
  • MCMX: maximum size of meta space (KB)
  • MC: current space size of meta space (KB)
  • CCSMN: minimum space size of compressed class space (KB)
  • CCSMX: maximum space size of compressed class space (KB)
  • CCSC: current space size of compressed class space (KB)
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly
  • FGCT: time consuming GC in the elderly
  • GCT: total GC time

7. Jstat gcnew: display Cenozoic statistics

C:\Users\Administrator>jstat -gcnew 2284 S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT 104832.0 104832.0 46710.2 0.0 6 6 52416.0 838912.0 22526.9 60 4.972
  • S0C: total space size of the first surviving area (KB)
  • S1C: total space size of the second survival area (KB)
  • S0U: used space size of the first survivor (KB)
  • S1U: used space size of the second survival area (KB)
  • TT: promotion threshold (promotion threshold)
  • MTT: maximum threshold
  • DSS: survivor area size (KB)
  • EC: total space size of Eden (KB)
  • EU: used space size of Eden (KB)

8. Jstat gcnewcapacity: Statistics of new generation and memory usage

C:\Users\Administrator>jstat -gcnewcapacity 2284 NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC 1048576.0 1048576.0 1048576.0 104832.0 104832.0 104832.0 104832.0 838912.0 838912.0 60 11
  • NGCMN: minimum space size of Cenozoic (KB)
  • NGCMX: maximum space size of Cenozoic (KB)
  • NGC: current Cenozoic space size (KB)
  • S0CMX: maximum space size of the first survival area (KB)
  • S0C: current space size of the first survivor (KB)
  • S1CMX: maximum space size of the second survival area (KB)
  • S1C: current space size of the second survival area (KB)
  • ECMX: maximum space size of Eden (KB)
  • EC: current space size of Eden (KB)
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly

9. Jstat gcold: Statistics of aging and Metaspace usage

C:\Users\Administrator>jstat -gcold 2284 MC MU CCSC CCSU OC OU YGC FGC FGCT GCT 251088.0 244521.5 23544.0 22058.7 1048576.0 565828.4 60 11 6.323 11.295
  • MC: total size of meta space (KB)
  • MU: used size of Metaspace (KB)
  • CCSC: total size of compressed class space (KB)
  • CCSU: used size of compressed class space (KB)
  • OC: total space size of elderly area (KB)
  • OU: used size of elderly area (KB)
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly
  • FGCT: total time of GC in the elderly
  • GCT: total GC time

10. Jstat gcoldcapacity: Statistics of memory usage in the old age

C:\Users\Administrator>jstat -gcoldcapacity 2284 OGCMN OGCMX OGC OC YGC FGC FGCT GCT 1048576.0 3145728.0 1048576.0 1048576.0 60 11 6.323 11.295
  • OGCMN: minimum space occupied by elderly area (KB)
  • OGCMX: maximum space occupied by elderly area (KB)
  • OGC: current elderly space (KB)
  • OC: current aged area space (KB)
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly
  • FGCT: total time of GC in the elderly
  • GCT: total GC time

11. Jstat - gcutil: garbage collection statistics

C:\Users\Administrator>jstat -gcutil 2284 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 44.56 0.00 9.85 53.96 97.38 93.69 60 4.972 11 6.323 11.295
  • S0: percentage of space used in the first surviving area
  • S1: percentage of space used in the second surviving area
  • E: Percentage of space used in Eden
  • O: Percentage of space used in the elderly
  • M: Percentage of meta space used
  • CCS: compressed space usage percentage
  • YGC: number of new generation GC
  • FGC: number of GC in the elderly
  • GCT: total GC time

12. Jstat - printcompilation: compilation statistics of Hotspot method

C:\Users\Administrator>jstat -printcompilation 2284 Compiled Size Type Method 21538 150 1 java/util/Collections reverse
  • Compiled: number of compiled methods
  • Size: last method compilation size
  • Type: last compiled method type
  • Method: last compiled method

reference resources:

jstat: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html
The jstat command uses: https://www.cnblogs.com/lizhonghua34/p/7307139.html
JVM tuning command - jstat: https://www.cnblogs.com/myna/p/7567769.html

jstack: View thread stack information in a Java process

Refer to the original text: https://www.jianshu.com/p/8d5782bc596e

View the thread content in the JAVA process.

jstack usage

/opt/java8/bin/jstack Usage: jstack [-l] <pid> (to connect to running process) Connect active threads jstack -F [-m] [-l] <pid> (to connect to a hung process) Connection blocking thread jstack [-m] [-l] <executable> <core> (to connect to a core file) connect dump Documents of jstack [-m] [-l] [server_id@]<remote server IP or hostname> (to connect to a remote debug server) Connect to remote server Options: -F to force a thread dump. Use when jstack <pid> does not respond (process is hung) -m to print both java and native frames (mixed mode) -l long listing. Prints additional information about locks -h or -help to print this help message

jstack View output

/opt/java8/bin/jstack -l 28367 2019-06-25 15:04:46 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode): "Attach Listener" #453 daemon prio=9 os_prio=0 tid=0x00007f9f94001000 nid=0xf30 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None "grpc-default-executor-263" #452 daemon prio=5 os_prio=0 tid=0x00007f9f4c01f800 nid=0x9aa waiting on condition [0x00007f9f398bd000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007400243f0> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - None "http-bio-8080-exec-10" #235 daemon prio=5 os_prio=0 tid=0x0000000001bcc800 nid=0x3c13 waiting on condition [0x00007f9f384a9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000743d26638> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - None

jstack count threads

/opt/java8/bin/jstack -l 28367 | grep 'java.lang.Thread.State' | wc -l

jstack detect deadlock

Deadlock code

public class DeathLock { private static Lock lock1 = new ReentrantLock(); private static Lock lock2 = new ReentrantLock(); public static void deathLock() { Thread t1 = new Thread() { @Override public void run() { try { lock1.lock(); TimeUnit.SECONDS.sleep(1); lock2.lock(); } catch (InterruptedException e) { e.printStackTrace(); } } }; Thread t2 = new Thread() { @Override public void run() { try { lock2.lock(); TimeUnit.SECONDS.sleep(1); lock1.lock(); } catch (InterruptedException e) { e.printStackTrace(); } } }; t1.setName("thread1"); t2.setName("thread2"); t1.start(); t2.start(); } public static void main(String[] args) { deathLock(); } }

Deadlock log

"mythread2" #12 prio=5 os_prio=0 tid=0x0000000058ef7800 nid=0x1ab4 waiting on condition [0x0000000059f8f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000d602d610> (a java.util.concurrent.lock s.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLo ck.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at DeathLock$2.run(DeathLock.java:34) Locked ownable synchronizers: - <0x00000000d602d640> (a java.util.concurrent.locks.ReentrantLock$Nonfa irSync) "mythread1" #11 prio=5 os_prio=0 tid=0x0000000058ef7000 nid=0x3e68 waiting on condition [0x000000005947f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000d602d640> (a java.util.concurrent.lock s.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLo ck.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at DeathLock$1.run(DeathLock.java:22) Locked ownable synchronizers: - <0x00000000d602d610> (a java.util.concurrent.locks.ReentrantLock$Nonfa irSync) Found one Java-level deadlock: ============================= "mythread2": waiting for ownable synchronizer 0x00000000d602d610, (a java.util.concurrent.l ocks.ReentrantLock$NonfairSync), which is held by "mythread1" "mythread1": waiting for ownable synchronizer 0x00000000d602d640, (a java.util.concurrent.l ocks.ReentrantLock$NonfairSync), which is held by "mythread2" Java stack information for the threads listed above: =================================================== "mythread2": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000d602d610> (a java.util.concurrent.lock s.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLo ck.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at DeathLock$2.run(DeathLock.java:34) "mythread1": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000d602d640> (a java.util.concurrent.lock s.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLo ck.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at DeathLock$1.run(DeathLock.java:22) Found 1 deadlock.

High cpu of jstack detection

Step 1: view the process with high cpu consumption

top Mem: 16333644k total, 9472968k used, 6860676k free, 165616k buffers Swap: 0k total, 0k used, 0k free, 6665292k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17850 root 20 0 7588m 112m 11m S 100.7 0.7 47:53.80 java 1552 root 20 0 121m 13m 8524 S 0.7 0.1 14:37.75 AliYunDun 3581 root 20 0 9750m 2.0g 13m S 0.7 12.9 298:30.20 java 1 root 20 0 19360 1612 1308 S 0.0 0.0 0:00.81 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.14 migration/0

Step 2: view the high cpu utilization threads

top -H -p 17850 top - 17:43:15 up 5 days, 7:31, 1 user, load average: 0.99, 0.97, 0.91 Tasks: 32 total, 1 running, 31 sleeping, 0 stopped, 0 zombie Cpu(s): 3.7%us, 8.9%sy, 0.0%ni, 87.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16333644k total, 9592504k used, 6741140k free, 165700k buffers Swap: 0k total, 0k used, 0k free, 6781620k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17880 root 20 0 7588m 112m 11m R 99.9 0.7 50:47.43 java 17856 root 20 0 7588m 112m 11m S 0.3 0.7 0:02.08 java 17850 root 20 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17851 root 20 0 7588m 112m 11m S 0.0 0.7 0:00.23 java 17852 root 20 0 7588m 112m 11m S 0.0 0.7 0:02.09 java 17853 root 20 0 7588m 112m 11m S 0.0 0.7 0:02.12 java 17854 root 20 0 7588m 112m 11m S 0.0 0.7 0:02.07 java

Step 3: convert thread ID

printf "%x\n" 17880 45d8

Step 4: locate the cpu occupying thread

jstack 17850|grep 45d8 -A 30 "pool-1-thread-11" #20 prio=5 os_prio=0 tid=0x00007fc860352800 nid=0x45d8 runnable [0x00007fc8417d2000] java.lang.Thread.State: RUNNABLE at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) - locked <0x00000006c6c2e708> (a java.io.BufferedOutputStream) at java.io.PrintStream.write(PrintStream.java:482) - locked <0x00000006c6c10178> (a java.io.PrintStream) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) - locked <0x00000006c6c26620> (a java.io.OutputStreamWriter) at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) at java.io.PrintStream.write(PrintStream.java:527) - eliminated <0x00000006c6c10178> (a java.io.PrintStream) at java.io.PrintStream.print(PrintStream.java:597) at java.io.PrintStream.println(PrintStream.java:736) - locked <0x00000006c6c10178> (a java.io.PrintStream) at com.demo.guava.HardTask.call(HardTask.java:18) at com.demo.guava.HardTask.call(HardTask.java:9) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "pool-1-thread-10" #19 prio=5 os_prio=0 tid=0x00007fc860345000 nid=0x45d7 waiting on condition [0x00007fc8418d3000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000006c6c14178> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

Jmap

Original reference: https://www.jianshu.com/p/c52ffaca40a5

Jmap is the tool software of JDK, which is mainly used to print the shared object memory mapping or heap memory details of the specified java process (or core file, remote debugging server). You can use jmap to generate Heap Dump. Java Dump and thread Dump are respectively introduced in Java command Java Dump and Java command: Jstack. This article mainly introduces Java Heap Dump and jmap command

What is a Dump

Basic knowledge

Memory composition and heap memory of Java virtual machine
How Java GC works

Common memory errors:

outOfMemoryError the old generation is out of memory.
outOfMemoryError:PermGen Space is running out of permanent memory.
Outofmemoryerror: GC overhead limit exceeded garbage collection time takes 98% or more of the system running time.

jmap Usage Summary

Usage: jmap [option] <pid> (to connect to running process) jmap [option] <executable <core> (to connect to a core file) jmap [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server) where <option> is one of: <none> to print same info as Solaris pmap -heap to print java heap summary -histo[:live] to print histogram of java object heap; if the "live" suboption is specified, only count live objects -permstat to print permanent generation statistics -finalizerinfo to print information on objects awaiting finalization -dump:<dump-options> to dump java heap in hprof binary format dump-options: live dump only live objects; if not specified, all objects in the heap are dumped. format=b binary format file=<file> dump heap to <file> Example: jmap -dump:live,format=b,file=heap.bin <pid> -F force. Use with -dump:<dump-options> <pid> or -histo to force a heap dump or histogram when <pid> does not respond. The "live" suboption is not supported in this mode. -h | -help to print this help message -J<flag> to pass <flag> directly to the runtime system
  • Jmap [option] of the process with the specified process number (pid)
  • Specify the core file jmap [option]
  • Specify the remote debugging server jmap [option] [server ID @]

Parameters:

  • The option option parameters are mutually exclusive (they cannot be used at the same time). If you want to use option parameters, just follow the command name directly.
  • pid needs to print the process ID of the configuration information. The process must be a java process. To get a list of running Java processes, you can use jps.
  • Executable the Java executable that produces the core dump.
  • Core needs to print the core file of configuration information.
  • Remote hostname or IP the hostname or IP address of the remote debugging server (see jsadebugd).
  • Server id optional unique id. if more than one debugging server is running on the same remote host, use this option parameter to identify the server.

Options:

  • If you use jmap without option parameters to print the mapping of shared objects, the starting address, mapping size and full path name of each shared object loaded in the target virtual machine will be printed. This is similar to the pmap tool of Solaris.
  • -dump:[live,]format=b,file = dump Java heap in hprof binary format to the file of specified filename. The live sub option is optional. If the live sub option is specified, only active objects in the heap are dumped. To browse heap dump, you can use jhat(Java heap analysis tool) to read the generated files.
  • -finalizerinfo prints the information of the object waiting for the end.
  • -Heap prints the summary information of a heap, including the GC algorithm used, heap configuration information, and generation wise heap usage.
  • -histo[:live] prints the histogram of the heap. This includes each Java class, number of objects, memory size (in bytes), and fully qualified class name. The printed class name inside the virtual machine will be prefixed with a '*'. If the live sub option is specified, only the active objects are evaluated.
  • -permstat prints intelligent statistics for classloaders in persistent storage areas of Java heap memory. For each class loader, its name, activity, address, parent class loader, number and size of classes it loads are printed. In addition, the number and size of the included strings are printed.
  • -F force mode. If the specified pid does not respond, use the jmap dump or jmap histo options. In this mode, the live sub option is not supported.
  • -h print help information.
  • -Help print help.
  • -J specifies the parameters passed to the JVM running jmap.

Example:

Check the usage of java heap and execute the command: jmap -heap 31846

Attaching to process ID 31846, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24.71-b01 using thread-local object allocation. Parallel GC with 4 thread(s)//GC mode Heap Configuration: //Heap memory initialization configuration MinHeapFreeRatio = 0 //Corresponding to the JVM startup parameter - XX:MinHeapFreeRatio, set the JVM heap minimum idle ratio (default 40) MaxHeapFreeRatio = 100 //Set the JVM heap maximum idle ratio (default 70) corresponding to the JVM startup parameter - XX:MaxHeapFreeRatio MaxHeapSize = 2082471936 (1986.0MB) //Corresponding JVM startup parameter - XX:MaxHeapSize = set the maximum size of JVM heap NewSize = 1310720 (1.25MB)//Corresponding JVM startup parameter - XX:NewSize = set the default size of 'new generation' of JVM heap MaxNewSize = 17592186044415 MB//Corresponding JVM startup parameter - XX:MaxNewSize = set the maximum size of the 'new generation' of JVM heap OldSize = 5439488 (5.1875MB)//Corresponding JVM startup parameter - XX: oldsize = < value >: set the size of the JVM heap's' generation of elders' NewRatio = 2 //Corresponding jvm startup parameter - XX:NewRatio =: size ratio of 'new generation' and 'old generation' SurvivorRatio = 8 //Corresponding jvm startup parameter - XX:SurvivorRatio = set the size ratio of Eden area and Survivor area in the young generation PermSize = 21757952 (20.75MB) //Corresponding JVM startup parameter - XX: permsize = < value >: set the initial size of the 'immortal' generation of the JVM heap MaxPermSize = 85983232 (82.0MB)//Corresponding JVM startup parameter - XX: maxpermsize = < value >: set the maximum size of the 'immortal generation' of the JVM heap G1HeapRegionSize = 0 (0.0MB) Heap Usage://Heap memory usage PS Young Generation Eden Space://Eden area memory distribution capacity = 33030144 (31.5MB)//Total capacity of Eden District used = 1524040 (1.4534378051757812MB) //Eden area used free = 31506104 (30.04656219482422MB) //Remaining capacity of Eden District 4.614088270399305% used //Utilization ratio of Eden District From Space: //Memory distribution of one Survivor area capacity = 5242880 (5.0MB) used = 0 (0.0MB) free = 5242880 (5.0MB) 0.0% used To Space: //Memory distribution of another Survivor area capacity = 5242880 (5.0MB) used = 0 (0.0MB) free = 5242880 (5.0MB) 0.0% used PS Old Generation //Current Old area memory distribution capacity = 86507520 (82.5MB) used = 0 (0.0MB) free = 86507520 (82.5MB) 0.0% used PS Perm Generation//Current memory distribution of "Immortality generation" capacity = 22020096 (21.0MB) used = 2496528 (2.3808746337890625MB) free = 19523568 (18.619125366210938MB) 11.337498256138392% used 670 interned Strings occupying 43720 bytes.

View the number and size of objects in the heap memory. Execute command: jmap -histo 3331

num #instances #bytes class name //Number byte class name ---------------------------------------------- 1: 7 1322080 [I 2: 5603 722368 <methodKlass> 3: 5603 641944 <constMethodKlass> 4: 34022 544352 java.lang.Integer 5: 371 437208 <constantPoolKlass> 6: 336 270624 <constantPoolCacheKlass> 7: 371 253816 <instanceKlassKlass>

Output the details of memory usage to a file, execute the command: jmap -dump:format=b,file=heapDump 6900

Then, with the jhat command, you can refer to jhat -port 5000 heapDump in the browser to access: http://localhost:5000/ View details

When this command is executed, the JVM will write the information dump of the whole heap to a file. If the heap is large, it will lead to a time-consuming process. In order to ensure that the information of dump is reliable, the application will be suspended.

summary

1. If the program is out of memory or GC frequently, there is likely to be a memory leak. At this time, you need to use the Java heap Dump to view the object.
2. To make heap Dump, you can directly use the jmap command provided by the jvm
3. You can first use jmap heap command to check the usage of the heap and the usage of each heap space.
4. Use jmap -histo:[live] to view the objects in the heap memory. If a large number of objects are continuously referenced and not released, there will be a memory leak. We need to release the unused objects in combination with the code.
5. You can also use the jmap -dump:format=b,file = command to save the heap information to a file, and then use the jhat command to view the details
6. In case of memory leakage, overflow or other preconditions, it is recommended to dump more memory several times to number and archive the memory files for subsequent memory sorting and analysis.

Problems:

  1. Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process
    Using jmap for the first time in ubuntu will report an error: Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process. This is a bug mentioned in the oracla document: Http: / / bugs. Java. COM / bugdatabase / view? Bug. Do? Bug? Id = 7050524, the solution is as follows:
  • Echo 0 | sudo TEE / proc / sys / kernel / Yama / ptrace | scope this method is valid before the next restart.
  • Permanent and effective method sudo vi /etc/sysctl.d/10-ptrace.conf Edit the following line: kernel.yama.ptrace_scope = 1 is modified to: kernel.yama.ptrace_scope = 0 restart the system for the changes to take effect.
    Zhao xiaopang's personal blog

18 May 2020, 05:01 | Views: 1473

Add new comment

For adding a comment, please log in
or create account

0 comments