Java-常用JVM命令

xxsd
188 阅读4分钟

 由于还在不断的整理及发现中，更加详细的内容请查看下面的笔记链接；

——>笔记链接点这里<——

一、JPS

查看进程；Linux下也可以使用；

这里顺便提一下：ps -ef|grep 【名称】

二、jmap

2.1）查看内存信息

查看实例个数以及占用内存大小

jmap -histo 【进程编号】 > .log.txt

num     #instances         #bytes  class name
----------------------------------------------
   1:      10370916      254565072  [Ljava.lang.Object;
   2:       5278512      126684288  java.util.ArrayList
   3:        751837       48218336  [C
   4:          7848       28051776  [I
   5:        154482       12829848  [B
   6:        521671       12520104  java.lang.String
   7:         90121        7930648  java.lang.reflect.Method
   8:        152516        4880512  java.util.HashMap$Node
   9:        105352        4214080  java.util.LinkedHashMap$Entry
  10:         27614        2806576  [Ljava.util.HashMap$Node;
  11:        168241        2691856  java.lang.Boolean
  12:         52523        2521104  java.util.HashMap
  13:         97314        2335536  java.lang.Long
  14:         70160        2245120  java.util.concurrent.ConcurrentHashMap$Node
  15:        106564        2155608  [Ljava.lang.Class;
  16:         44122        2117856  com.silk.model.entity.UserSimpleness
说明：
num：序号；
instances：实例数量
byte：占用空间大小，单位“字节”；
class name：相关的类名称；[Ljava.lang.Object;标识的是Object数组；

2.2）查看堆信息

查看进程JVM总体的情况；

jmap -heap 【进程编号】

Attaching to process ID 5272, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 734003200 (700.0MB)
   NewSize                  = 89128960 (85.0MB)
   MaxNewSize               = 244318208 (233.0MB)
   OldSize                  = 179306496 (171.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:#真正堆使用的信息
PS Young Generation
Eden Space:
   capacity = 67108864 (64.0MB)
   used     = 2697928 (2.5729446411132812MB)
   free     = 64410936 (61.42705535888672MB)
   4.020226001739502% used
From Space:
   capacity = 11010048 (10.5MB)
   used     = 0 (0.0MB)
   free     = 11010048 (10.5MB)
   0.0% used
To Space:
   capacity = 11010048 (10.5MB)
   used     = 0 (0.0MB)
   free     = 11010048 (10.5MB)
   0.0% used
PS Old Generation
   capacity = 118489088 (113.0MB)
   used     = 5147504 (4.9090423583984375MB)
   free     = 113341584 (108.09095764160156MB)
   4.344285272918971% used

5966 interned Strings occupying 526280 bytes.

2.3）导出Dump文件

jmap -dump:format=b,file=【文件名称】.hprof 【进程编号】
导出后的Dump文件可以使用jvisualvm工具进行查看；
在系统启动中加入如下参数：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=【地址路径及文件名称】.dump

三、jstack

3.1)排除死锁问题

/**
 * 类描述:  死锁演示代码
 * <br />
 * 运行后在控制台使用Jstack命令查看
 * <p>
 * 命令：jstack 【进程号】
 *
 * @author xxsd
 * @version 1.0.0
 * @date 2020/8/7 0007 下午 4:40
 */
public class DeadLockTest {
    private static Object lockObject1 = new Object();
    private static Object lockObject2 = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (lockObject1) {
                try {
                    System.out.println("thread1 begin");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                }
                synchronized (lockObject2) {
                    System.out.println("thread1 end");
                }
            }
        }).start();
        new Thread(() -> {
            synchronized (lockObject2) {
                try {
                    System.out.println("thread2 begin");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                }
                synchronized (lockObject1) {
                    System.out.println("thread2 end");
                }
            }
        }).start();
        System.out.println("main thread end");
    }
}

在控制台使用jstack 【进程号】命令后的结果为：
2020-08-07 16:46:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode):

"DestroyJavaVM" #14 prio=5 os_prio=0 tid=0x0000000003333800 nid=0x7ef4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #13 prio=5 os_prio=0 tid=0x000000001fc6e000 nid=0xa1a4 waiting for monitor entry [0x000000002052f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at lock.DeadLockTest.lambda$main$1(DeadLockTest.java:39)
        - waiting to lock <0x000000076b589578> (a java.lang.Object)
        - locked <0x000000076b589588> (a java.lang.Object)
        at lock.DeadLockTest$Lambda$2/317574433.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Thread-0" #12 prio=5 os_prio=0 tid=0x000000001fc6d000 nid=0x5fd8 waiting for monitor entry [0x000000002042f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at lock.DeadLockTest.lambda$main$0(DeadLockTest.java:27)
        - waiting to lock <0x000000076b589588> (a java.lang.Object)
        - locked <0x000000076b589578> (a java.lang.Object)
        at lock.DeadLockTest$Lambda$1/883049899.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #11 daemon prio=9 os_prio=0 tid=0x000000001ee94800 nid=0x2ea4 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #10 daemon prio=9 os_prio=2 tid=0x000000001ee00000 nid=0x5f50 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001edf1000 nid=0x5e10 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x000000001edee800 nid=0x5e74 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x000000001eded800 nid=0x8d80 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001edd2000 nid=0x7d98 runnable [0x000000001f52e000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x000000076b6d1cf0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x000000076b6d1cf0> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000001ec69800 nid=0x8c6c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001ec69000 nid=0x905c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001ec50800 nid=0x1818 in Object.wait() [0x000000001f22f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b408ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x000000076b408ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x000000001ce4d000 nid=0x7098 in Object.wait() [0x000000001f12f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b406bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x000000076b406bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x000000001ce48800 nid=0x7c7c runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000003349000 nid=0x9e1c runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000334a800 nid=0x711c runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000334c800 nid=0x8970 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000334e000 nid=0x64d4 runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000003350000 nid=0x6bb4 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000003352800 nid=0x5260 runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000003355800 nid=0x27bc runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000003356800 nid=0x6e3c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001ee9a800 nid=0x2894 waiting on condition

JNI global references: 317

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x000000001ce53588 (object 0x000000076b589578, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x000000001ce50cf8 (object 0x000000076b589588, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at lock.DeadLockTest.lambda$main$1(DeadLockTest.java:39)
        - waiting to lock <0x000000076b589578> (a java.lang.Object)
        - locked <0x000000076b589588> (a java.lang.Object)
        at lock.DeadLockTest$Lambda$2/317574433.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at lock.DeadLockTest.lambda$main$0(DeadLockTest.java:27)
        - waiting to lock <0x000000076b589588> (a java.lang.Object)
        - locked <0x000000076b589578> (a java.lang.Object)
        at lock.DeadLockTest$Lambda$1/883049899.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.
"Thread-1" 线程名

prio=5 优先级=5

tid=0x000000001fc6e000线程id

nid=0x7ef4 线程对应的本地线程标识nid

java.lang.Thread.State: BLOCKED 线程状态

3.2)定位占用cpu最高的线程堆栈信息

/**
 * 类描述:  线程堆栈占用CPU最高——实例Demo
 * <br />
 * 使用jstack找出占用CPU最高的堆栈信息
 *
 * @author xxsd
 * @version 1.0.0
 * @date 2020/8/7 0007 下午 5:04
 */
public class Math {

    public static final int initData = 666;

    public static User user = new User();

    /**
     * 功能描述：一个方法对应一块栈帧内存区域
     *
     * @author : xxsd
     * @date : 2020/8/7 0007 下午 5:18
     */
    public int compute() {
        int a = 1;
        int b = 3;
        int c = (a + b) * 10;
        return c;
    }

    public static void main(String[] values) {
        Math math = new Math();
        while (true) {
            math.compute();
        }
    }
}

class User {
    private String userName;
    private String userDate;

    public String getUserName() {
        return userName;
    }

    public void setUserName(String userName) {
        this.userName = userName;
    }

    public String getUserDate() {
        return userDate;
    }

    public void setUserDate(String userDate) {
        this.userDate = userDate;
    }
}
1，使用命令top -p ，显示你的[Java](http://lib.csdn.net/base/java)进程的内存情况，pid是你的java进程号，比如19663；
![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/104b265d845447fcaf283d33c058cfcb~tplv-k3u1fbpfcp-zoom-1.image)

2，按H，获取每个线程的内存情况 ；

3，找到内存和cpu占用最高的线程pid，比如19664 ；

4，执行 System.out.println(Integer.toHexString(19664)); 得到 0x4cd0,此为线程id的十六进制 ；

5，执行 jstack 4977|grep -A 10 4cd0，得到线程堆栈信息中 4cd0 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法；

6，查看对应的堆栈信息找出可能存在问题的代码；

四、jinfo

查看正在运行的Java应用程序扩展参数；
查看JVM参数：jinfo -flags 【进程号】

查看系统参数：jinfo -sysprops 【进程号】

五、jstat

可以查看堆内存各部分的使用量，加载类的数量。

jstat -gc 【进程号】【间隔毫秒】 【打印多少次】

5.1）统计GC

jstat -gc pid 最常用，可以评估程序内存使用及GC压力整体情况
![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ae546d7d067a45f19bd298c90672f4ba~tplv-k3u1fbpfcp-zoom-1.image)
  • S0C：第一个幸存区的大小，单位KB
  • S1C：第二个幸存区的大小
  • S0U：第一个幸存区的使用大小S1U：第二个幸存区的使用大小
  • EC：伊甸园区的大小
  • EU：伊甸园区的使用大小
  • OC：老年代大小
  • OU：老年代使用大小
  • MC：方法区大小(元空间)
  • MU：方法区使用大小
  • CCSC:压缩类空间大小
  • CCSU:压缩类空间使用大小
  • YGC：年轻代垃圾回收次数
  • YGCT：年轻代垃圾回收消耗时间，单位s
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间，单位s
  • GCT：垃圾回收消耗总时间，单位s

5.2）统计堆

命令：jstat -gccapacity 【进程编号】
![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f58acd8b56ec470cbceb1794b54b1bb9~tplv-k3u1fbpfcp-zoom-1.image)
  • NGCMN：新生代最小容量
  • NGCMX：新生代最大容量
  • NGC：当前新生代容量
  • S0C：第一个幸存区大小
  • S1C：第二个幸存区的大小
  • EC：伊甸园区的大小
  • OGCMN：老年代最小容量
  • OGCMX：老年代最大容量
  • OGC：当前老年代大小
  • OC:当前老年代大小
  • MCMN:最小元数据容量
  • MCMX：最大元数据容量
  • MC：当前元数据空间大小
  • CCSMN：最小压缩类空间大小
  • CCSMX：最大压缩类空间大小
  • CCSC：当前压缩类空间大小
  • YGC：年轻代gc次数
  • FGC：老年代GC次数

5.3）新生代垃圾回收统计

命令：jstat -gcnew 【进程编号】
![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82a1b4b5bee84b62a5e5c5f89f0df25f~tplv-k3u1fbpfcp-zoom-1.image)
  • S0C：第一个幸存区的大小
  • S1C：第二个幸存区的大小
  • S0U：第一个幸存区的使用大小
  • S1U：第二个幸存区的使用大小
  • TT:对象在新生代存活的次数
  • MTT:对象在新生代存活的最大次数
  • DSS:期望的幸存区大小
  • EC：伊甸园区的大小
  • EU：伊甸园区的使用大小
  • YGC：年轻代垃圾回收次数
  • YGCT：年轻代垃圾回收消耗时间

5.3）新生代内存统计

命令：jstat -gcnewcapacity 【进程编号】
![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d855d0093b7a47e3bd18380f421be077~tplv-k3u1fbpfcp-zoom-1.image)
  • NGCMN：新生代最小容量
  • NGCMX：新生代最大容量
  • NGC：当前新生代容量
  • S0CMX：最大幸存1区大小
  • S0C：当前幸存1区大小
  • S1CMX：最大幸存2区大小
  • S1C：当前幸存2区大小
  • ECMX：最大伊甸园区大小
  • EC：当前伊甸园区大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代回收次数

5.4）老年代垃圾回收统计

命令：jstat -gcold 【进程编号】
![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2afe34c4c12a41359ef6f5e48c78d1e2~tplv-k3u1fbpfcp-zoom-1.image)
  • MC：方法区大小
  • MU：方法区使用大小
  • CCSC:压缩类空间大小
  • CCSU:压缩类空间使用大小
  • OC：老年代大小
  • OU：老年代使用大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

5.5）老年代内存统计

命令：jstat -gcoldcapacity 【进程编号】
![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a2b5d43dc2994009b69a00242cc068e9~tplv-k3u1fbpfcp-zoom-1.image)
  • OGCMN：老年代最小容量
  • OGCMX：老年代最大容量
  • OGC：当前老年代大小
  • OC：老年代大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

5.6）元数据空间统计

命令：jstat -gcmetacapacity 【进程编号】

  • MCMN:最小元数据容量
  • MCMX：最大元数据容量
  • MC：当前元数据空间大小
  • CCSMN：最小压缩类空间大小
  • CCSMX：最大压缩类空间大小
  • CCSC：当前压缩类空间大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

5.6）垃圾回收单位比例

命令：jstat -gcutil 【进程编号】
![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6b5b5f2ea9ac456fb3643fe32823f319~tplv-k3u1fbpfcp-zoom-1.image)
  • S0：幸存1区当前使用比例
  • S1：幸存2区当前使用比例
  • E：伊甸园区使用比例
  • O：老年代使用比例
  • M：元数据区使用比例
  • CCS：压缩使用比例
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

六、VisualVM

远程链接参数：
java ‐Dcom.sun.management.jmxremote.port=8888 ‐Djava.rmi.server.hostname=192.168.50.60 ‐Dcom.sun.management.jmxremote.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false ‐jar microservice‐eureka‐server.jar
说明：
-Dcom.sun.management.jmxremote.port 为远程机器的JMX端口
-Djava.rmi.server.hostname 为远程机器IP
**tomcat的JMX配置：在catalina.sh文件里的最后一个JAVA_OPTS的赋值语句下一行增加如下配置行**
JAVA_OPTS="$JAVA_OPTS ‐Dcom.sun.management.jmxremote.port=8888 ‐Djava.rmi.server.hostname=192.168.50.60 ‐Dcom.sun.management.jmxremote.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false"
avatar
文章
阅读
粉丝