5-commands commonly used by JVM

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 ${PID} looks at the parameter value of the JVM in a JAVA process.

jinfo -flag ${PID} 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 ${PID}

For example: jstat -class ${PID} ${prints once in a few seconds} ${prints 10 times} = jstat -class ${PID} 1000 10. Print out the data loaded by the class in the past 10 seconds.

GC related situation: jstat -gc ${PID}

For example: jstat -gc ${PID} ${print once in a few seconds} ${print 10 times} = jstat -gc ${PID} 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

Tags: Java jvm Tomcat JDK

Posted on Mon, 18 May 2020 05:01:09 -0400 by Kingy