在实践中使用Jstat监控gc情况

http://rdc.taobao.com/blog/qa/?p=1198

性能测试过程中，我们该如何监控java虚拟机内存的使用情况，用以判断JVM是否存在内存问题呢？如何判断JVM垃圾回收是否正常？一般的top指令基本上满足不了这样的需求，因为它主要监控的是总体的系统资源，很难定位到java应用程序。

在项目实践过程中，我们探索和使用了一款新工具－－Jstat。

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

那，该怎么用呢？

语法结构如下：jstat [Options] vmid [interval] [count]

Options — 选项，我们一般使用 -gcutil 查看gc情况

vmid — VM的进程号，即当前运行的java进程号

interval– 间隔时间，单位为秒或者毫秒

count — 打印次数，如果缺省则打印无数次

下面给出一个实际的例子：



注：由于JVM
内存设置较大，图中百分比变化不太明显

图中参数含义如下：

S0 — Heap上的 Survivor space 0 区已使用空间的百分比

S1 — Heap上的 Survivor space 1 区已使用空间的百分比

E — Heap上的 Eden space 区已使用空间的百分比

O — Heap上的 Old space 区已使用空间的百分比

P — Perm space 区已使用空间的百分比

YGC — 从应用程序启动到采样时发生 Young GC 的次数

YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)

FGC — 从应用程序启动到采样时发生 Full GC 的次数

FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)

GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

上图的示例，红框中，我们可以看到，5次young gc之后，垃圾内存被从Eden space区(E)放入了Old
space区(O)，并引起了百分比的变化，导致Survivor
space使用的百分比从19.69%(S0)降到10.34%(S1)。有效释放了内存空间。绿框中，我们可以看到，一次full gc之后，Old
space区(O)的内存被回收，从36.81%降到35.01%。

图中同时打印了young gc和full gc的总次数、总耗时。而，每次young
gc消耗的时间，可以用相间隔的两行YGCT相减得到。每次full
gc消耗的时间，可以用相隔的两行FGCT相减得到。例如红框中表示的第一行、第二行之间发生了1次young
gc，消耗的时间为52.281-52.252＝0.029秒。

常驻内存区(P)的使用率，始终停留在37.6%左右，说明常驻内存没有突变，比较正常。

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