jstat [Options] vmid [interval] [count]

Options，选项，我们一般使用 -gcutil 查看gc情况
vmid，VM的进程号，即当前运行的java进程号
interval，间隔时间，单位为秒或者毫秒
count，打印次数，如果缺省则打印无数次

通常运行命令如下：

jstat -gc 12538 5000

即会每5秒一次显示进程号为12538的java进成的GC情况，

显示内容如下图：

显示内容说明如下（部分结果是通过其他其他参数显示的，暂不说明）：

         S0C：年轻代中第一个survivor（幸存区）的容量 (字节) 
         S1C：年轻代中第二个survivor（幸存区）的容量 (字节) 
         S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节) 
         S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节) 
         EC：年轻代中Eden（伊甸园）的容量 (字节) 
         EU：年轻代中Eden（伊甸园）目前已使用空间 (字节) 
         OC：Old代的容量 (字节) 
         OU：Old代目前已使用空间 (字节) 
         PC：Perm(持久代)的容量 (字节) 
         PU：Perm(持久代)目前已使用空间 (字节) 
         YGC：从应用程序启动到采样时年轻代中gc次数 
         YGCT：从应用程序启动到采样时年轻代中gc所用时间(s) 
         FGC：从应用程序启动到采样时old代(全gc)gc次数 
         FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s) 
         GCT：从应用程序启动到采样时gc用的总时间(s) 
         NGCMN：年轻代(young)中初始化(最小)的大小 (字节) 
         NGCMX：年轻代(young)的最大容量 (字节) 
         NGC：年轻代(young)中当前的容量 (字节) 
         OGCMN：old代中初始化(最小)的大小 (字节) 
         OGCMX：old代的最大容量 (字节) 
         OGC：old代当前新生成的容量 (字节) 
         PGCMN：perm代中初始化(最小)的大小 (字节) 
         PGCMX：perm代的最大容量 (字节)   
         PGC：perm代当前新生成的容量 (字节) 
         S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比 
         S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比 
         E：年轻代中Eden（伊甸园）已使用的占当前容量百分比 
         O：old代已使用的占当前容量百分比 
         P：perm代已使用的占当前容量百分比 
         S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节) 
         S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节) 
         ECMX：年轻代中Eden（伊甸园）的最大容量 (字节) 
         DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满） 
         TT： 持有次数限制 
         MTT ： 最大持有次数限制 

实战部分

当然jstat更多的是监控jvm的内存动向，在实战性能调优中也可以用其他工具作为补充，如jconsole，vm等工具，接下来将结合jstack和procexp线程检测工具来做（linux下可以使用ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu命令来查看pid相应的tid）。

首先本地安装proecxp，然后打开如下图

上图的pid为7684的进程下有N多个线程，在tomcat异常的情况时线程的使用率是飙高的，这个时候可以根据对应的tid在jstack打印出的堆日志里进行匹配，注：在stack日志里的nid对应这里的tid，且是16进制的 所以需要将tid的10进制转到16进制在做匹配

第一步：找到该javaw所对应的pid，linux下可以用ps -ef|grep javaw命令，windows上可以使用tasklist|findstr "javaw"找到pid

第二步：使用jstack -l7684>7684_stack.txt（在本文中使用pid为7684作为演示，上面图片的pid后来因为作者停了一次服务，所以导致pid变更）

第三步：以tid 7192为例，将其转为16进制为1c18

则匹配到stack日志里的

"Abandoned connection cleanup thread" daemon prio=6 tid=0x0000000015738000 nid=0x1c18 in Object.wait() [0x00000000182ef000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007cb0b4cc8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x00000007cb0b4cc8> (a java.lang.ref.ReferenceQueue$Lock)
at com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:41)


   Locked ownable synchronizers:
- None

注意：如果在线程使用率异常的时候，在stack信息里会详细标注是在程序中的哪一行代码里造成的，由于时间原因就不做演示，谢谢阅读。