JVM问题定位的瑞士军刀——JCMD

jcmd是jdk自带的一个神器，能够很方便的对java程序进行profiling。jcmd其实可以替代很多常用的工具，比如jstak，jmap。接下来让我们了解下什么是jcmd，jcmd能够帮助我们定位什么问题？工作中我们如何使用jcmd。

从jdk7开始，jcmd就是jdk自带的一个工具。在正确配置了jdk的path的情况下，我们可以直接在命令行中执行jcmd:

[root@vincent-testing ~]# jcmd -h
usage: jcmd <pid | main class> <command ...|perfcounter.print|-f file>
   or: jcmd -l
   or: jcmd -h

  command must be a valid jcmd command for the selected jvm.
  use the command "help" to see which commands are available.
  if the pid is 0, commands will be sent to all java processes.
  the main class argument will be used to match (either partially
  or fully) the class used to start java.
  if no options are given, lists java processes (same as -p).

  perfcounter.print display the counters exposed by this process
  -f  read and execute commands from the file
  -l  list jvm processes on the local machine
  -h  this help

利用jcmd，我们能做很多事情，比如，抓现场堆栈(dump threads)，抓运行时堆内存(dump heap),采集gc日志，定位高cpu占用问题等。

列出机器上运行的jvm

在没有jcmd的时候，我们也有很多找出jvm进程的方法，比如：linux下通过ps，使用jdk自带的jps等。使用jcmd，我们同样可以做到：

[root@vincent-testing ~]# jcmd -l
13714 sun.tools.jcmd.jcmd -l
16324 org.rzo.yajsw.app.wrapperjvmmain
9350 org.rzo.yajsw.app.wrapperjvmmain
9815 org.apache.catalina.startup.bootstrap start

通过jcmd -l可以列出所有的java程序，其功能和jps其实是一样的。

操作指定的jvm进程

列出所有的jvm程序，找到你感兴趣的进程id，运行jcmd <pid> help，看看我们可以做些什么：

[root@vincent-testing ~]# jcmd 9350 help
9350:
the following commands are available:
jfr.stop
jfr.start
jfr.dump
jfr.check
vm.native_memory
vm.check_commercial_features
vm.unlock_commercial_features
managementagent.stop
managementagent.start_local
managementagent.start
gc.rotate_log
thread.print
gc.class_stats
gc.class_histogram
gc.heap_dump
gc.run_finalization
gc.run
vm.uptime
vm.flags
vm.system_properties
vm.command_line
vm.version
help

for more information about a specific command use 'help <command>'.

可以看到，jcmd给我们提供了很多的功能。这里我们先说几个简单的。

抓现场堆栈

相信大部分的java程序员肯定都用过jstack，通过jstack可以dump当前jvm的线程堆栈。通过jstack <pid> thread.print可以达到一样的目的:

➜  ~ jcmd 3426 thread.print
3426:
2018-08-02 21:36:07
full thread dump java hotspot(tm) 64-bit server vm (25.144-b01 mixed mode):

"attach listener" #16 daemon prio=9 os_prio=31 tid=0x00007fd9a43d0000 nid=0xd07 waiting on condition [0x0000000000000000]
   java.lang.thread.state: runnable

"nettythreaddeathwatcher-2-1" #15 daemon prio=1 os_prio=31 tid=0x00007fd9a4ca1800 nid=0xa903 waiting on condition [0x0000700005924000]
   java.lang.thread.state: timed_waiting (sleeping)
    at java.lang.thread.sleep(native method)
    at io.netty.util.threaddeathwatcher$watcher.run(threaddeathwatcher.java:152)
    at io.netty.util.concurrent.defaultthreadfactory$defaultrunnabledecorator.run(defaultthreadfactory.java:144)
    at java.lang.thread.run(thread.java:748)

"destroyjavavm" #14 prio=5 os_prio=31 tid=0x00007fd9a3b7f800 nid=0x1a03 waiting on condition [0x0000000000000000]
   java.lang.thread.state: runnable
....  other threads ommited ... 

如果想要在线程dump中包含锁信息，需要加上-l=true:

➜  ~ jcmd 3426  thread.print -l=true
3426:
2018-08-02 21:39:08
full thread dump java hotspot(tm) 64-bit server vm (25.144-b01 mixed mode):

"attach listener" #16 daemon prio=9 os_prio=31 tid=0x00007fd9a43d0000 nid=0xd07 waiting on condition [0x0000000000000000]
   java.lang.thread.state: runnable

   locked ownable synchronizers:
    - none

"nettythreaddeathwatcher-2-1" #15 daemon prio=1 os_prio=31 tid=0x00007fd9a4ca1800 nid=0xa903 waiting on condition [0x0000700005924000]
   java.lang.thread.state: timed_waiting (sleeping)
    at java.lang.thread.sleep(native method)
    at io.netty.util.threaddeathwatcher$watcher.run(threaddeathwatcher.java:152)
    at io.netty.util.concurrent.defaultthreadfactory$defaultrunnabledecorator.run(defaultthreadfactory.java:144)
    at java.lang.thread.run(thread.java:748)

   locked ownable synchronizers:
    - none
.... other threads ommited

抓取堆内存

➜  ~ jcmd 3426 help gc.heap_dump
3426:
gc.heap_dump
generate a hprof format dump of the java heap.

impact: high: depends on java heap size and content. request a full gc unless the '-all' option is specified.

permission: java.lang.management.managementpermission(monitor)

syntax : gc.heap_dump [options] <filename>

arguments:
    filename :  name of the dump file (string, no default value)

options: (options must be specified using the <key> or <key>=<value> syntax)
    -all : [optional] dump all objects, including unreachable objects (boolean, false)

如果你定位过内存泄漏相关的问题，那么你肯定知道如何dump堆内存，或者查看堆内存中的类分布。通常之前我们使用的工具是jmap，使用jcmd转存堆内存的方法是使用gc.heap_dump。

➜  ~ jcmd 3426 gc.heap_dump test.dump
3426:
heap dump file created

通常情况，在dump堆内存钱会触发一次full gc，如果不希望触发full gc，可以指定参数all=true，即:

➜  ~ jcmd 3426 gc.heap_dump test2.dump -all=true
3426:
heap dump file created

统计堆内存使用情况

转存堆内存并分析相对来说比较复杂，一个更简单的方法是统计堆中对象的直方图。在没有jcmd的时候，我通常是使用jmap来统计堆中对象的分布，如果想使用jcmd统计堆中对象的分布，使用jcmd <pid> gc.class_histogram。

---

jcmd命令中包还有其他很多工具，大家如果感兴趣可以通过jcmd <pid> help <command>查看。在没有jcmd工具之前，我们通常需要组合使用多个不同的工具进行问题定位，而现在只需要使用jcmd一个命令就可以了。除了替代现有的工具之后，jcmd还支持更高级的profiling功能，录制jfr来分析jvm的性能。

[文章同步发布在我的上，欢迎拍砖。
传送门： jvm问题定位的瑞士军刀——jcmd