jps、jinfo、jstat、jstack、jmap、jconsole等命令简介

ref:http://blog.csdn.net/caihaijiang/article/details/6084325

JDK提供了几个很实用的工具，如下：

jinfo：观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数，java class path等信息。命令格式：jinfo 进程pid
jps：用来显示本地的java进程，可以查看本地运行着几个java程序，并显示他们的进程号。命令格式：jps   或 jps 远程服务ip地址    （默认端口1099）
jstat：一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。

jstack：可以观察到jvm中当前所有线程的运行情况和线程当前状态。, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。命令格式：jstack 进程pid
jmap：观察运行中的jvm物理内存的占用情况（如：产生哪些对象，及其数量）。命令格式：jmap [option] pid

      option参数如下：
             -heap：打印jvm heap的情况
             -histo：打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
             -histo：live ：同上，但是只答应存活对象的情况
             -permstat：打印permanent generation heap情况

       使用jmap进行 heap dump的例子： jmap -dump:format=b,file=<filename> <pid>  

       打印内存统计图：jmap -histo:live <pid>

       结果中每行显示了当前堆中每种类类型的信息，包含被分配的实例个数及其消耗的字节数。选项“live”，表示只统计存活的对象

       需要注意的是，jmap不是运行分析工具，在生成统计图时JVM可能会暂停，因此当生成统计图时需要确认这种暂停对程序是可接受的。
jconsole：一个java GUI监视工具，可以以图表化的形式显示各种数据。并可通过远程连接监视远程的服务器VM。

 

这些命令的使用，见官方文档：
jps：http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jps.html
jstat：http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html

jstack：http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstack.html
jmap：http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html
jconsole：http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

 

 jstat的一些参数：

参数名称

描述

class

统计class loader行为信息。命令例子：jstat -class pid 1000 10 （每隔1秒监控一次，一共做10次），输出内容，含义如下：

LoadedNumber of classes loaded.BytesNumber of Kbytes loaded.UnloadedNumber of classes unloaded.BytesNumber of Kbytes unloaded.TimeTime spent performing class load and unload operations.

 

compile

统计编译行为信息。

gc

输出每个堆区域的当前可用空间以及已用空间（伊甸园，幸存者等等），GC执行的总次数，GC操作累计所花费的时间。

gccapactiy

输出每个堆区域的最小空间限制（ms）/最大空间限制（mx），当前大小，每个区域之上执行GC的次数。（不输出当前已用空间以及GC执行时间）。

gccause

输出-gcutil提供的信息以及最后一次执行GC的发生原因和当前所执行的GC的发生原因

gcnew

输出新生代空间的GC性能数据

gcnewcapacity

输出新生代空间的大小的统计数据。

gcold

输出老年代空间的GC性能数据。

gcoldcapacity

输出老年代空间的大小的统计数据。

gcpermcapacity

输出持久带空间的大小的统计数据。

gcutil

输出每个堆区域使用占比，以及GC执行的总次数和GC操作所花费的事件。

 

你可以只关心那些最常用的命令，你会经常用到 -gcutil (或-gccause), -gc and –gccapacity。

·         -gcutil 被用于检查堆间的使用情况，GC执行的次数以及GC操作所花费的时间。

·         -gccapacity以及其他的参数可以用于检查实际分配内存的大小。

不同的jstat参数输出不同类型的列，如下表所示，根据你使用的”jstat option”会输出不同列的信息。

列说明Jstat参数S0C输出Survivor0空间的大小。单位KB。-gc
-gccapacity
-gcnew
-gcnewcapacityS1C输出Survivor1空间的大小。单位KB。-gc
-gccapacity
-gcnew
-gcnewcapacityS0U输出Survivor0已用空间的大小。单位KB。-gc
-gcnewS1U输出Survivor1已用空间的大小。单位KB。-gc
-gcnewEC输出Eden空间的大小。单位KB。-gc
-gccapacity
-gcnew
-gcnewcapacityEU输出Eden已用空间的大小。单位KB。-gc
-gcnewOC输出老年代空间的大小。单位KB。-gc
-gccapacity
-gcold
-gcoldcapacityOU输出老年代已用空间的大小。单位KB。-gc
-gcoldPC输出持久代空间的大小。单位KB。-gc
-gccapacity
-gcold
-gcoldcapacity
-gcpermcapacityPU输出持久代已用空间的大小。单位KB。-gc
-gcoldYGC新生代空间GC时间发生的次数。-gc
-gccapacity
-gcnew
-gcnewcapacity
-gcold
-gcoldcapacity
-gcpermcapacity
-gcutil
-gccauseYGCT新生代GC处理花费的时间。-gc
-gcnew
-gcutil
-gccauseFGCfull GC发生的次数。-gc
-gccapacity
-gcnew
-gcnewcapacity
-gcold
-gcoldcapacity
-gcpermcapacity
-gcutil
-gccauseFGCTfull GC操作花费的时间-gc
-gcold
-gcoldcapacity
-gcpermcapacity
-gcutil
-gccauseGCTGC操作花费的总时间。-gc
-gcold
-gcoldcapacity
-gcpermcapacity
-gcutil
-gccauseNGCMN新生代最小空间容量，单位KB。-gccapacity
-gcnewcapacityNGCMX新生代最大空间容量，单位KB。-gccapacity
-gcnewcapacityNGC新生代当前空间容量，单位KB。-gccapacity
-gcnewcapacityOGCMN老年代最小空间容量，单位KB。-gccapacity
-gcoldcapacityOGCMX老年代最大空间容量，单位KB。-gccapacity
-gcoldcapacityOGC老年代当前空间容量制，单位KB。-gccapacity
-gcoldcapacityPGCMN持久代最小空间容量，单位KB。-gccapacity
-gcpermcapacityPGCMX持久代最大空间容量，单位KB。-gccapacity
-gcpermcapacityPGC持久代当前空间容量，单位KB。-gccapacity
-gcpermcapacityPC持久代当前空间大小，单位KB-gccapacity
-gcpermcapacityPU持久代当前已用空间大小，单位KB-gc
-gcoldLGCC最后一次GC发生的原因-gccauseGCC当前GC发生的原因-gccauseTT老年化阈值。被移动到老年代之前，在新生代空存活的次数。-gcnewMTT最大老年化阈值。被移动到老年代之前，在新生代空存活的次数。-gcnewDSSAdequate size of survivor in KB
幸存者区所需空间大小，单位KB。-gcnew

参考文章：http://www.importnew.com/2057.html

 

下面内容，摘自：http://jameswxx.javaeye.com/blog/731763

在本机执行 jstat -gcutil 340 10000，这个命令是每个10秒钟输出一次jvm的gc信息，10000指的是间隔时间为10000毫秒。屏幕上显示如下信息（我只取了第一行，因为是按的一定频率显示，所以实际执行的时候，会有很多行）：

   S0       S1       E        O          P       YGC     YGCT    FGC    FGCT     GCT  
 54.62   0.00  42.87  43.52  86.24   1792    5.093     33       7.670   12.763

[xhtml] view plaincopy

1. S0:新生代的susvivor0区，空间使用率为54..62%  
2. S1:新生代的susvivor1区，空间使用率为0.00%(因为还没有执行第二次minor收集)  
3. E:eden区，空间使用率42.87%  
4. O:旧生代，空间使用率43.52%  
5. P:持久带，空间使用率86.24%  
6. YGC:minor gc执行次数1792次  
7. YGCT:minor gc耗费的时间5.093毫秒  
8. FGC:full gc执行次数33  
9. FGCT:full gc耗费的时间7.670毫秒  
10. GCT:gc耗费的总时间12.763毫秒   

如果young gc和full gc能够正常发生，而且都能有效回收内存，常驻内存区变化不明显，则说明java内存释放情况正常，垃圾回收及时，java内存泄露的几率就会大大降低。但也不能说明一定没有内存泄露。

每次young gc消耗的时间，可以用相间隔的两行YGCT相减得到。每次full gc消耗的时间，可以用相隔的两行FGCT相减得到

官方文档的一个例子：

[plain] view plaincopy

1. Using the gcutil option  
2.   
3. This example attaches to lvmid 21891 and takes 7 samples at 250 millisecond intervals and displays the output as specified by the -gcutil option.  
4.   
5. jstat -gcutil 21891 250 7  
6.   S0     S1     E      O      P     YGC    YGCT    FGC    FGCT     GCT  
7.  12.44   0.00  27.20   9.49  96.70    78    0.176     5    0.495    0.672  
8.  12.44   0.00  62.16   9.49  96.70    78    0.176     5    0.495    0.672  
9.  12.44   0.00  83.97   9.49  96.70    78    0.176     5    0.495    0.672  
10.   0.00   7.74   0.00   9.51  96.70    79    0.177     5    0.495    0.673  
11.   0.00   7.74  23.37   9.51  96.70    79    0.177     5    0.495    0.673  
12.   0.00   7.74  43.82   9.51  96.70    79    0.177     5    0.495    0.673  
13.   0.00   7.74  58.11   9.51  96.71    79    0.177     5    0.495    0.673  
14. The output of this example shows that a young generation collection occurred between the 3rd an

例子： 

1. 发现问题

    最近在检查爬虫程序运行情况的时候发现采集速度非常慢，查看cpu占用率的时候发现有一个内核一直是100%，按理说多线程的程序不应该会出现这样的情况。第一反应就是用jstack -l [pid]把线程dump出来查看栈情况，但没发现什么异常。然后就考虑用jmap -heap [pid]把内存使用情况打印出来看看，奇怪的是出现好几次连接不上的情况，等打印出来发现居然旧生代已经满了。把内存调大，发现过不了一会又是这样，确实非常蹊跷。

2. 深入调查

    看来问题比较棘手，只好用更细致的方式去分析了。一方面打开了GC日志，同时在运行时用jstat -gcutil [pid] 1000来跟踪GC情况。现象很奇怪，旧生代空间缓慢增长，但突然新生代内存占用100%，旧生代紧接着也变成100%，然后就一直处于full gc，但内存丝毫没有减少，整个过程持续了5分钟。（截图忘记保存了，悲剧...）

    看现象就是对象爆炸，但程序已经运行很久了，如果有这么严重的bug应该早就发现了。严谨起见，我用jmap -histo [pid]把程序的对象情况打印出来，结果非常惊讶。

num     #instances         #bytes  class name 
--------------------------------------------- 
  1:      30110820     1204432800  org.jsoup.parser.ParseError 
  2:         33076      156025088  [Ljava.lang.Object; 
  3:         68836       98796360  [C 

    系统中居然出现那么多ParserError对象，这个是程序中用到的一个Jsoup开源包里面的东西。看命名像是一个Exception，但查看源码时才发现居然是一个Class。至于这个东西从哪里蹦出来的呢？！我在现象出现的时候打印了下线程栈信息，果然定位到了生成这个对象的那个位置。

    在源码中找到相应的实现，主要是调用了这样一个方法：

private boolean trackErrors = true;
......
void error(TokeniserState state) { 
    if (trackErrors) 
        errors.add(new ParseError("Unexpected character in input", reader.current(), state, reader.pos())); 
} 

    这里有一个trackErrors做开关，默认是true，但找了一下，居然没有最外层的方法去控制它，而errors这个对象也是一个private值，没有任何调用，可能是作者自己测试用的。

3. 问题的处理

    原因调查清楚，处理就很简单了。直接把源码中trackErrors的默认值改成false，再确认了一下其他相关调用的方法，然后重新编译打包，把原始包替换了。

4. 总结

    找问题还是要先分析出可能的原因，然后借用工具去定位问题，很多时候数据比经验更可靠。