jvm监控命令介绍

Posted 2020-08-17 路之石

1.jstack介绍

　　如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。

　　

命令格式

$jstack [ option ] pid

$jstack [ option ] executable core

$jstack [ option ] [[email protected]]remote-hostname-or-IP

参数说明:

pid: java应用程序的进程号,一般可以通过jps来获得;

executable:产生core dump的java可执行程序; 

core:打印出的core文件;

remote-hostname-or-ip:远程debug服务器的名称或IP;

server-id: 唯一id,假如一台主机上多个远程debug服务; 

 

示例:

$jstack –l 23561

 

线程分析:

一般情况下，通过jstack输出的线程信息主要包括：jvm自身线程、用户线程等。其中jvm线程会在jvm启动时就会存在。对于用户线程则是在用户访问时才会生成。

l jvm线程：

在线程中，有一些 JVM内部的后台线程，来执行譬如垃圾回收，或者低内存的检测等等任务，这些线程往往在JVM初始化的时候就存在，如下所示：

"Attach Listener" daemon prio=10 tid=0x0000000052fb8000 nid=0xb8f waiting on condition [0x0000000000000000]    java.lang.Thread.State: RUNNABLE      Locked ownable synchronizers:         - None destroyJavaVM" prio=10 tid=0x00002aaac1225800 nid=0x7208 waiting on condition [0x0000000000000000]    java.lang.Thread.State: RUNNABLE      Locked ownable synchronizers:         - None

l 用户级别的线程

还有一类线程是用户级别的，它会根据用户请求的不同而发生变化。该类线程的运行情况往往是我们所关注的重点。而且这一部分也是最容易产生死锁的地方。

"qtp496432309-42" prio=10 tid=0x00002aaaba2a1800 nid=0x7580 waiting on condition [0x00000000425e9000]    java.lang.Thread.State: TIMED_WAITING (parking)         at sun.misc.Unsafe.park(Native Method)         - parking to wait for  <0x0000000788cfb020> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)         at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)         at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)         at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:320)         at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:479)         at java.lang.Thread.run(Thread.java:662)      Locked ownable synchronizers:         - None

从上述的代码示例中我们可以看到该用户线程的以下几类信息：

? 线程的状态：waiting on condition(等待条件发生)

? 线程的调用情况；

? 线程对资源的锁定情况；

 

线程的状态分析：

正如我们刚看到的那样，线程的状态是一个重要的指标，它会显示在线程每行结尾的地方。那么线程常见的有哪些状态呢？线程在什么样的情况下会进入这种状态呢？我们能从中发现什么线索？

l Runnable

该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。 

l Waiton condition 

该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。 

如果发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。 

另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。 

l Waitingfor monitor entry 和 in Object.wait() 

在多线程的 JAVA程序中，实现线程之间的同步，就要说说Monitor。Monitor是Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。下面这个图，描述了线程和 Monitor之间关系，以及线程的状态转换图： 

 

从图中可以看出，每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitorentry”，而在 “Wait Set”中等待的线程状态是“in Object.wait()”。 

先看 “Entry Set”里面的线程。我们称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像： 

synchronized(obj){ 

......... 

} 

这时有两种可能性： 

该 monitor不被其它线程拥有，Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码 。此时线程将处于Runnable状态；

该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。此时dump的信息显示“waiting for monitor entry”。

"Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000..0xf927bdb8]  at testthread.WaitThread.run(WaitThread.java:39)  - waiting to lock <0xef63bf08> (a java.lang.Object)  - locked <0xef63beb8> (a java.util.ArrayList)  at java.lang.Thread.run(Thread.java:595)

临界区的设置，是为了保证其内部的代码执行的原子性和完整性。但是因为临界区在任何时间只允许线程串行通过，这和我们多线程的程序的初衷是相反的。如果在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在线程 DUMP中发现了这个情况，应该审查源码，改进程序。 

现在我们再来看现在线程为什么会进入 “Wait Set”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ， “ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的Monitor，恢复到运行态。在 “Wait Set”中的线程， DUMP中表现为： in Object.wait()，类似于： 

"Thread-1" prio=10 tid=0x08223250 nid=0xa in Object.wait() [0xef47a000..0xef47aa38]  at java.lang.Object.wait(Native Method)  - waiting on <0xef63beb8> (a java.util.ArrayList)  at java.lang.Object.wait(Object.java:474)  at testthread.MyWaitThread.run(MyWaitThread.java:40)  - locked <0xef63beb8> (a java.util.ArrayList)  at java.lang.Thread.run(Thread.java:595)

仔细观察上面的 DUMP信息，你会发现它有以下两行： 

2 locked <0xef63beb8> (ajava.util.ArrayList) 

2 waiting on <0xef63beb8> (ajava.util.ArrayList) 

这里需要解释一下，为什么先 lock了这个对象，然后又 waiting on同一个对象呢？让我们看看这个线程对应的代码： 

synchronized(obj){

......... 

obj.wait();

......... 

} 

线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于 locked <0xef63beb8> ）。当执行到 obj.wait(), 线程即放弃了 Monitor的所有权，进入 “wait set”队列（对应于 waiting on<0xef63beb8> ）。 

往在你的程序中，会出现多个类似的线程，他们都有相似的 dump也可能是正常的。比如，在程序中有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被notify，当然只有一个线程获得了 lock，继续执行，而其它线程继续等待。 

 

2.jmap

　　

Jmap是一个可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成文本。打印出某个Java进程（使用pid）内存内的，所有‘对象’的情况（如：产生那些对象，及其数量）。

使用方法 jmap -histo pid。如果使用SHELL ,可采用jmap -histo pid>a.log日志将其保存到文件中，在一段时间后，使用文本对比工具，可以对比出GC回收了哪些对象。jmap -dump:format=b,file=outfile 3024可以将3024进程的内存heap输出出来到outfile文件里，再配合MAT（内存分析工具）。

 

命令格式

l  jmap [ option ] pid

l  jmap [ option ] executable core

l  jmap [ option ] [[email protected]]remote-hostname-or-IP

3、参数说明

1)、options： 

l  executable :产生core dump的java可执行程序;

l  core 将被打印信息的core dump文件;

l  remote-hostname-or-IP 远程debug服务的主机名或ip;

l  server-id 唯一id,假如一台主机上多个远程debug服务;

2）、基本参数：

?  -dump:[live,]format=b,file=<filename> 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件. 

$jmap–dump:live,format=b,file=aaa.bin 3772 

?  -finalizerinfo 打印正等候回收的对象的信息

$jmap -finalizerinfo 3772

Attaching to process ID 3772, please wait... Debugger attached successfully. Server compiler detected. JVM version is 20.0-b11 Number of objects pending for finalization: 0 (等候回收的对象为0个)

?  -heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况.

$jmap –heap 3772

using parallel threads in the new generation.  ##新生代采用的是并行线程处理方式 using thread-local object allocation.    Concurrent Mark-Sweep GC   ##同步并行垃圾回收   Heap Configuration:  ##堆配置情况    MinHeapFreeRatio = 40 ##最小堆使用比例    MaxHeapFreeRatio = 70 ##最大堆可用比例    MaxHeapSize      = 2147483648 (2048.0MB) ##最大堆空间大小    NewSize          = 268435456 (256.0MB) ##新生代分配大小    MaxNewSize       = 268435456 (256.0MB) ##最大可新生代分配大小    OldSize          = 5439488 (5.1875MB) ##老生代大小    NewRatio         = 2  ##新生代比例    SurvivorRatio    = 8 ##新生代与suvivor的比例    PermSize         = 134217728 (128.0MB) ##perm区大小    MaxPermSize      = 134217728 (128.0MB) ##最大可分配perm区大小   Heap Usage: ##堆使用情况 New Generation (Eden + 1 Survivor Space):  ##新生代（伊甸区 + survior空间）    capacity = 241631232 (230.4375MB)  ##伊甸区容量    used     = 77776272 (74.17323303222656MB) ##已经使用大小    free     = 163854960 (156.26426696777344MB) ##剩余容量    32.188004570534986% used ##使用比例 Eden Space:  ##伊甸区    capacity = 214827008 (204.875MB) ##伊甸区容量    used     = 74442288 (70.99369812011719MB) ##伊甸区使用    free     = 140384720 (133.8813018798828MB) ##伊甸区当前剩余容量    34.65220164496263% used ##伊甸区使用情况 From Space: ##survior1区    capacity = 26804224 (25.5625MB) ##survior1区容量    used     = 3333984 (3.179534912109375MB) ##surviror1区已使用情况    free     = 23470240 (22.382965087890625MB) ##surviror1区剩余容量    12.43827838477995% used ##survior1区使用比例 To Space: ##survior2 区    capacity = 26804224 (25.5625MB) ##survior2区容量    used     = 0 (0.0MB) ##survior2区已使用情况    free     = 26804224 (25.5625MB) ##survior2区剩余容量    0.0% used ## survior2区使用比例 concurrent mark-sweep generation: ##老生代使用情况    capacity = 1879048192 (1792.0MB) ##老生代容量    used     = 30847928 (29.41887664794922MB) ##老生代已使用容量    free     = 1848200264 (1762.5811233520508MB) ##老生代剩余容量    1.6416783843721663% used ##老生代使用比例 Perm Generation: ##perm区使用情况    capacity = 134217728 (128.0MB) ##perm区容量    used     = 47303016 (45.111671447753906MB) ##perm区已使用容量    free     = 86914712 (82.8883285522461MB) ##perm区剩余容量    35.24349331855774% used ##perm区使用比例

?  -histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量. 

$jmap–histo:live 3772

num     #instances         #bytes  class name ----------------------------------------------    1:         65220        9755240  <constMethodKlass>    2:         65220        8880384  <methodKlass>    3:         11721        8252112  [B    4:          6300        6784040  <constantPoolKlass>    5:         75224        6218208  [C    6:         93969        5163280  <symbolKlass>    7:          6300        4854440  <instanceKlassKlass>    8:          5482        4203152  <constantPoolCacheKlass>    9:         72097        2307104  java.lang.String   10:         15102        2289912  [I   11:          4089        2227728  <methodDataKlass>   12:         28887        1386576  org.apache.velocity.runtime.parser.Token   13:          6792         706368  java.lang.Class   14:          7445         638312  [Ljava.util.HashMap$Entry;   15:          8770         607040  [S   16:         17802         569664  java.lang.ref.WeakReference   17:          9538         472688  [[I   18:          8439         470440  [Ljava.lang.Object;   19:          5168         454784  java.lang.reflect.Method   20:         12559         401888  java.util.HashMap$Entry   21:          3730         358080  org.apache.velocity.runtime.parser.node.ASTReference   22:          4373         279872  org.apache.velocity.runtime.parser.node.ASTText   23:           463         270392  <objArrayKlassKlass>   24:          6695         267800  java.lang.ref.SoftReference   25:          5198         249504  java.util.HashMap   26:          2871         206712  org.apache.velocity.runtime.parser.node.ASTIdentifier   27:          7526         180624  org.apache.velocity.util.introspection.Info   28:          4441         177640  java.util.LinkedHashMap$Entry   29:          5550         177600  java.util.concurrent.locks.ReentrantLock$NonfairSync   30:          5723         175272  [Lorg.apache.velocity.runtime.parser.node.Node;   31:          4473         156904  [Ljava.lang.String;   32:          2773         155288  java.beans.MethodDescriptor   33:          6264         150336  java.util.ArrayList

?  -permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来. 

$jmap -permstat 3772

class_loader    classes bytes   parent_loader   alive?  type   <bootstrap>     2172    13144040          null          live    <internal> 0x00000007882d7ab8      0       0       0x0000000788106c00      dead    java/util/[email protected] 0x0000000788c15ca8      1       3136    0x00000007880213d8      dead    sun/reflect/[email protected] 0x0000000788fb1718      1       1968    0x00000007880213d8      dead    sun/reflect/[email protected] 0x00000007882d0f08      1       2008    0x00000007880213d8      dead    sun/reflect/[email protected] 0x0000000788176c60      1       3112    0x00000007880213d8      dead    sun/reflect/[email protected] 0x0000000788a7e018      1       3144    0x00000007880213d8      dead    sun/reflect/[email protected] 0x0000000788f515d0      1       1984    0x00000007880213d8      dead    sun/reflect/[email protected] 0x000000078829a2c8      1       3112    0x00000007880213d8      dead    sun/reflect/[email protected] 0x0000000788fab478      1       3128      null          dead    sun/reflect/[email protected] 0x0000000788030fd8      1       3112    0x00000007880213d8      dead    sun/reflect/[email protected] 0x0000000788d46048      1       3144    0x00000007880213d8      dead    sun/reflect/[email protected] 0x000000078816f6f0      1       3144      null          dead    sun/reflect/[email protected] 0x0000000788c18850      1       3112    0x00000007880213d8      dead    sun/reflect/[email protected]

?  -F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效. 

?  -h | -help 打印辅助信息 

?  -J 传递参数给jmap启动的jvm. 

 

3.Jstat

Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于Java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。可见，Jstat是轻量级的、专门针对JVM的工具，非常适用。

jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id，和所选参数。参考格式如下：

jstat -options 

可以列出当前JVM版本支持的选项，常见的有

 

• l  class (类加载器) 
• l  compiler (JIT) 
• l  gc (GC堆状态) 
• l  gccapacity (各区大小) 
• l  gccause (最近一次GC统计和原因) 
• l  gcnew (新区统计)
• l  gcnewcapacity (新区大小)
• l  gcold (老区统计)
• l  gcoldcapacity (老区大小)
• l  gcpermcapacity (永久区大小)
• l  gcutil (GC统计汇总)
• l  printcompilation (HotSpot编译统计)

 

1、jstat –class<pid> : 显示加载class的数量，及所占空间等信息。

显示列名	具体描述
Loaded	装载的类的数量
Bytes	装载类所占用的字节数
Unloaded	卸载类的数量
Bytes	卸载类的字节数
Time	装载和卸载类所花费的时间

2、jstat -compiler <pid>显示VM实时编译的数量等信息。

显示列名	具体描述
Compiled	编译任务执行数量
Failed	编译任务执行失败数量
Invalid	编译任务执行失效数量
Time	编译任务消耗时间
FailedType	最后一个编译失败任务的类型
FailedMethod	最后一个编译失败任务所在的类及方法

3、jstat -gc <pid>: 可以显示gc的信息，查看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)

4、jstat -gccapacity <pid>:可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小

显示列名	具体描述
NGCMN	年轻代(young)中初始化(最小)的大小(字节)
NGCMX	年轻代(young)的最大容量 (字节)
NGC	年轻代(young)中当前的容量 (字节)
S0C	年轻代中第一个survivor（幸存区）的容量 (字节)
S1C	年轻代中第二个survivor（幸存区）的容量 (字节)
EC	年轻代中Eden（伊甸园）的容量 (字节)
OGCMN	old代中初始化(最小)的大小 (字节)
OGCMX	old代的最大容量(字节)
OGC	old代当前新生成的容量 (字节)
OC	Old代的容量 (字节)
PGCMN	perm代中初始化(最小)的大小 (字节)
PGCMX	perm代的最大容量 (字节)
PGC	perm代当前新生成的容量 (字节)
PC	Perm(持久代)的容量 (字节)
YGC	从应用程序启动到采样时年轻代中gc次数
FGC	从应用程序启动到采样时old代(全gc)gc次数

5、jstat -gcutil <pid>:统计gc信息

显示列名	具体描述
S0	年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1	年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E	年轻代中Eden（伊甸园）已使用的占当前容量百分比
O	old代已使用的占当前容量百分比
P	perm代已使用的占当前容量百分比
YGC	从应用程序启动到采样时年轻代中gc次数
YGCT	从应用程序启动到采样时年轻代中gc所用时间(s)
FGC	从应用程序启动到采样时old代(全gc)gc次数
FGCT	从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT	从应用程序启动到采样时gc用的总时间(s)

6、jstat -gcnew <pid>:年轻代对象的信息。

显示列名	具体描述
S0C	年轻代中第一个survivor（幸存区）的容量 (字节)
S1C	年轻代中第二个survivor（幸存区）的容量 (字节)
S0U	年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U	年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
TT	持有次数限制
MTT	最大持有次数限制
EC	年轻代中Eden（伊甸园）的容量 (字节)
EU	年轻代中Eden（伊甸园）目前已使用空间 (字节)
YGC	从应用程序启动到采样时年轻代中gc次数
YGCT	从应用程序启动到采样时年轻代中gc所用时间(s)

7、jstat -gcnewcapacity<pid>: 年轻代对象的信息及其占用量。

显示列名	具体描述
NGCMN	年轻代(young)中初始化(最小)的大小(字节)
NGCMX	年轻代(young)的最大容量 (字节)
NGC	年轻代(young)中当前的容量 (字节)
S0CMX	年轻代中第一个survivor（幸存区）的最大容量 (字节)
S0C	年轻代中第一个survivor（幸存区）的容量 (字节)
S1CMX	年轻代中第二个survivor（幸存区）的最大容量 (字节)
S1C	年轻代中第二个survivor（幸存区）的容量 (字节)
ECMX	年轻代中Eden（伊甸园）的最大容量 (字节)
EC	年轻代中Eden（伊甸园）的容量 (字节)
YGC	从应用程序启动到采样时年轻代中gc次数
FGC	从应用程序启动到采样时old代(全gc)gc次数

8、jstat -gcold <pid>：old代对象的信息。

显示列名	具体描述
PC	Perm(持久代)的容量 (字节)
PU	Perm(持久代)目前已使用空间 (字节)
OC	Old代的容量 (字节)
OU	Old代目前已使用空间 (字节)
YGC	从应用程序启动到采样时年轻代中gc次数
FGC	从应用程序启动到采样时old代(全gc)gc次数
FGCT	从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT	从应用程序启动到采样时gc用的总时间(s)

9、stat -gcoldcapacity <pid>: old代对象的信息及其占用量。

显示列名	具体描述
OGCMN	old代中初始化(最小)的大小 (字节)
OGCMX	old代的最大容量(字节)
OGC	old代当前新生成的容量 (字节)
OC	Old代的容量 (字节)
YGC	从应用程序启动到采样时年轻代中gc次数
FGC	从应用程序启动到采样时old代(全gc)gc次数
FGCT	从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT	从应用程序启动到采样时gc用的总时间(s)

 

10、jstat -gcpermcapacity<pid>: perm对象的信息及其占用量。

显示列名	具体描述
PGCMN	perm代中初始化(最小)的大小 (字节)
PGCMX	perm代的最大容量 (字节)
PGC	perm代当前新生成的容量 (字节)
PC	Perm(持久代)的容量 (字节)
YGC	从应用程序启动到采样时年轻代中gc次数
FGC	从应用程序启动到采样时old代(全gc)gc次数
FGCT	从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT	从应用程序启动到采样时gc用的总时间(s)

 

11、jstat -printcompilation <pid>：当前VM执行的信息。

显示列名	具体描述
Compiled	编译任务的数目
Size	方法生成的字节码的大小
Type	编译类型
Method	类名和方法名用来标识编译的方法。类名使用/做为一个命名空间分隔符。方法名是给定类中的方法。上述格式是由-XX:+PrintComplation选项进行设置的