JVM (11)-the command line processing tool that comes with the JDK

I explained a lot of JVM memory structure and object creation. These are the basis of JVM, but the ultimate goal is to be able to tune it. Sometimes the application fails to respond and reports OOM, or memory leaks, or death. To solve these problems, it is indispensable to learn some command line tools that come with jdk. With the foundation of these tools, you will not only restart to solve the problem when you encounter a problem, but can start from Solve the problems of the application at the root cause, thereby improving the internal power of Java development

Generally speaking, the commonly used jdk tools are as follows:

  • jps: view all java processes
  • jstat: monitor various operating status information of virtual machines
  • jinfo: View and adjust various parameters of the virtual machine in real time
  • jmap: Generate heap storage snapshot
  • jhat: Analyze the heapdump file
  • jstack: Generate a thread snapshot of the virtual machine at the current moment

One, JDK comes with tools

jps: View all Java processes

jps(JVM Process Status) command UNIX-like pscommands.

jps: Displays the name of the main class of virtual machine execution and the unique ID (Local Virtual Machine Identifier, LVMID) of these processes.

jps -q : Only output the unique ID of the local virtual machine of the process.

jps -l: Output the full name of the main class. If the process is executing the Jar package, output the Jar path.

jps -v: Output the JVM parameters when the virtual machine process starts.

jps -m: Output the parameters passed to the main() function of the Java process.

jstat: Monitor various operating status information of virtual machines

jstat (JVM Statistics Monitoring Tool) is a command line tool used to monitor various operating status information of virtual machines. It can display class information, memory, garbage collection, JIT compilation and other running data in the virtual machine process locally or remotely (requires RMI support from the remote host). On a server that does not have a GUI and only provides a plain text console environment, it It will be the tool of choice for locating virtual machine performance problems during operation.

jstat Command format:

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

For example, jstat -gc -h3 31736 1000 10shows an analysis process with id 31736 gc case, the record is printed once every 1000ms, 10 times to stop printing, printing indicators head after every three lines.

Common options are as follows:

  • jstat -class vmid :Display related information of ClassLoader;
  • jstat -compiler vmid :Display related information of JIT compilation;
  • jstat -gc vmid : Display heap information related to GC;
  • jstat -gccapacity vmid : Display the capacity and usage of each generation;
  • jstat -gcnew vmid : Display new generation information;
  • jstat -gcnewcapcacity vmid :Display the size and usage of the new generation;
  • jstat -gcold vmid : Display the behavior statistics of the old generation and permanent generation. Starting from jdk1.8, this option only indicates the old generation because the permanent generation has been removed;
  • jstat -gcoldcapacity vmid : Display the size of the old age;
  • jstat -gcpermcapacity vmid : Display the size of the permanent generation. Starting from jdk1.8, this option no longer exists because the permanent generation has been removed;
  • jstat -gcutil vmid : Display garbage collection information;

Further, with -tthe parameters listed may be added in a Timestamp information is output to display the running time of the program.

jinfo: View and adjust various parameters of the virtual machine in real time

jinfo vmid : Output all the parameters and system attributes of the current JVM process (the first part is the system attributes, and the second part is the JVM parameters).

jinfo -flag name vmid: Output the specific value of the parameter corresponding to the name. For example, output MaxHeapSize and check whether the current jvm process is enabled to print GC logs ( -XX:PrintGCDetails: detailed GC log mode, both of which are disabled by default).

C:\Users\SnailClimb>jinfo  -flag MaxHeapSize 17340
-XX:MaxHeapSize=2124414976
C:\Users\SnailClimb>jinfo  -flag PrintGC 17340
-XX:-PrintGC

Using jinfo, you can dynamically modify the parameters of the jvm without restarting the virtual machine. Especially the online environment is particularly useful, please see the following example:

jinfo -flag [+|-]name vmid Turn on or turn off the parameter of the corresponding name.

C:\Users\SnailClimb>jinfo  -flag  PrintGC 17340
-XX:-PrintGC

C:\Users\SnailClimb>jinfo  -flag  +PrintGC 17340

C:\Users\SnailClimb>jinfo  -flag  PrintGC 17340
-XX:+PrintGC

jmap: Generate heap dump snapshot

jmapThe (Memory Map for Java) command is used to generate heap dump snapshots. If you do not use jmapcommand, in order to obtain the Java heap dump, you can use “-XX:+HeapDumpOnOutOfMemoryError”parameters, allowing virtual machines to automatically generate dump files after the OOM exception occurs, the Linux command can kill -3exit the process can send a signal to get the dump file.

jmapThe role of is not only to get the dump file, it can also query the finalizer execution queue, Java heap and permanent generation detailed information, such as space usage, which collector is currently used, etc. And jinfo, as jmapthere are many features in the Windows platform it is also restricted.

Example: Output a heap snapshot of a specified application to the desktop. Later, you can analyze the heap file with tools such as jhat and Visual VM.

C:\Users\SnailClimb>jmap -dump:format=b,file=C:\Users\SnailClimb\Desktop\heap.hprof 17340
Dumping heap to C:\Users\SnailClimb\Desktop\heap.hprof ...
Heap dump file created

jhat: Analyze the heapdump file

jhat Used to analyze the heapdump file, it will establish an HTTP/HTML server, so that users can view the analysis results on the browser.

C:\Users\SnailClimb>jhat C:\Users\SnailClimb\Desktop\heap.hprof
Reading from C:\Users\SnailClimb\Desktop\heap.hprof...
Dump file created Sat May 04 12:30:31 CST 2019
Snapshot read, resolving...
Resolving 131419 objects...
Chasing references, expect 26 dots..........................
Eliminating duplicate references..........................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

Visit http://localhost:7000/

jstack : Generate a thread snapshot of the virtual machine at the current moment

jstackThe (Stack Trace for Java) command is used to generate a thread snapshot of the virtual machine at the current moment. A thread snapshot is a collection of method stacks being executed by each thread in the current virtual machine.

The purpose of generating a thread snapshot is mainly to locate the cause of the thread stalling for a long time, such as deadlock between threads, infinite loops, and long waits caused by requesting external resources, which are all reasons for the thread to stall for a long time. When a thread is stalled, by jstacklooking at the call stack of each thread, you can know what the unresponsive thread is doing in the background, or what resources it is waiting for.

Below is the code for a thread deadlock. Here we will pass jstacka command to check the deadlock, deadlock output information, find the thread deadlock.

public class DeadLockDemo {
    
    
    private static Object resource1 = new Object();//资源 1
    private static Object resource2 = new Object();//资源 2

    public static void main(String[] args) {
    
    
        new Thread(() -> {
    
    
            synchronized (resource1) {
    
    
                System.out.println(Thread.currentThread() + "get resource1");
                try {
    
    
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
    
    
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource2");
                synchronized (resource2) {
    
    
                    System.out.println(Thread.currentThread() + "get resource2");
                }
            }
        }, "线程 1").start();

        new Thread(() -> {
    
    
            synchronized (resource2) {
    
    
                System.out.println(Thread.currentThread() + "get resource2");
                try {
    
    
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
    
    
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource1");
                synchronized (resource1) {
    
    
                    System.out.println(Thread.currentThread() + "get resource1");
                }
            }
        }, "线程 2").start();
    }
}

Output

Thread[线程 1,5,main]get resource1
Thread[线程 2,5,main]get resource2
Thread[线程 1,5,main]waiting get resource2
Thread[线程 2,5,main]waiting get resource1

Thread A obtains the monitor lock of resource1 through synchronized (resource1), and then Thread.sleep(1000);sleeps thread A for 1s in order to allow thread B to be executed and then obtain the monitor lock of resource2. Thread A and Thread B both begin to request resources from each other after they have finished sleeping, and then the two threads will fall into a state of waiting for each other, which also produces a deadlock.

By jstackcommand analysis:

C:\Users\SnailClimb>jps
13792 KotlinCompileDaemon
7360 NettyClient2
17396
7972 Launcher
8932 Launcher
9256 DeadLockDemo
10764 Jps
17340 NettyServer

C:\Users\SnailClimb>jstack 9256

Part of the output is as follows:

Found one Java-level deadlock:
=============================
"线程 2":
  waiting to lock monitor 0x000000000333e668 (object 0x00000000d5efe1c0, a java.lang.Object),
  which is held by "线程 1"
"线程 1":
  waiting to lock monitor 0x000000000333be88 (object 0x00000000d5efe1d0, a java.lang.Object),
  which is held by "线程 2"

Java stack information for the threads listed above:
===================================================
"线程 2":
        at DeadLockDemo.lambda$main$1(DeadLockDemo.java:31)
        - waiting to lock <0x00000000d5efe1c0> (a java.lang.Object)
        - locked <0x00000000d5efe1d0> (a java.lang.Object)
        at DeadLockDemo$$Lambda$2/1078694789.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"线程 1":
        at DeadLockDemo.lambda$main$0(DeadLockDemo.java:16)
        - waiting to lock <0x00000000d5efe1d0> (a java.lang.Object)
        - locked <0x00000000d5efe1c0> (a java.lang.Object)
        at DeadLockDemo$$Lambda$1/1324119927.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

You can see jstackthe command has helped us to get the details thread deadlock.

Guess you like

Origin blog.csdn.net/weixin_44706647/article/details/115210558