使用JDK自带工具jstat发现内存泄露问题

使用JDK自带工具jstat发现内存泄露问题

当你的java程序出现outofmemory异常而你需要重现分析并诊断时，或者你想检查你的应用程序是否有内存泄露的问题时，你该怎么办呢？很明显，top, ps之类的工具是远远不够的，这时候你可以选择一些工具，比如Jprobe,Jprofiler,Rational Purify等等，他们很好用，但是他们确实卖得很贵；或许我们首先得考虑一下JDK自带的一些免费工具，比如: jstack, jconsole, jinfo, jmap, jdb, jstat

这里就来简单介绍一下怎么使用jstat去发现应用程序潜在的内存泄露问题。（当然，很多文字都是copy/paste凑合在一起的呵呵...）
jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id，和所选参数。
执行：cd $JAVA_HOME/bin中执行jstat，注意jstat后一定要跟参数。

jstat 命令结构：

Usage: jstat -help|-options

       jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

jstat 参数解释

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

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

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

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

Options选项

-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况
-printcompilation：在Java的方法被编译时，打印其跟踪信息

例子

下面是我运行这个命令时候的截屏(典型的outofmemory先兆！):

其中输出内容含义如下

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 — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

监控内存使用情况 参数 （查看内存溢出相对有用）

jstat -gccause 2083 5000 （每隔5秒监控一次）

输出内容含义如下：

下面有必要介绍一下JVM内存分配机制和GC机制：

Jvm把内存分为两大块，一个是none heap和 heap，也就是：永久存储区（Permanent Space）和堆空间（The Heap Space）。 其中堆空间又分为新生区（Young (New) generation space）和养老区（Tenure (Old) generation space），新生区又分为伊甸园（Eden space），幸存者0区（Survivor 0 space）和幸存者1区（Survivor 1 space）。具体分区如下图：

永久存储区（Permanent Space）：永久存储区是JVM的驻留内存，用于存放JDK自身所携带的Class,Interface的元数据，应用服务器允许必须的 Class,Interface的元数据和Java程序运行时需要的Class和Interface的元数据。被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM时，释放此区域所控制的内存。

堆空间（The Heap Space）：是JAVA对象生死存亡的地区，JAVA对象的出生，成长，死亡都在这个区域完成。堆空间又分别按JAVA对象的创建和年龄特征分为养老区和新生区。

新生区（Young (New) generation space）：新生区的作用包括JAVA对象的创建和从JAVA对象中筛选出能进入养老区的JAVA对象。

伊甸园（Eden space）：JAVA对空间中的所有对象在此出生，该区的名字因此而得名。也即是说当你的JAVA程序运行时，需要创建新的对象，JVM将在该区为你创建一个指定的对象供程序使用。创建对象的依据即是永久存储区中的元数据。

幸存者0区（Survivor 0 space）和幸存者1区（Survivor1 space）：当伊甸园的控件用完时，程序又需要创建对象；此时JVM的垃圾回收器将对伊甸园区进行垃圾回收，将伊甸园区中的不再被其他对象所引用的对象进行销毁工作。同时将伊甸园中的还有其他对象引用的对象移动到幸存者0区。幸存者0区就是用于存放伊甸园垃圾回收时所幸存下来的JAVA对象。当将伊甸园中的还有其他对象引用的对象移动到幸存者0区时，如果幸存者0区也没有空间来存放这些对象时，JVM的垃圾回收器将对幸存者0区进行垃圾回收处理，将幸存者0区中不在有其他对象引用的JAVA对象进行销毁，将幸存者0区中还有其他对象引用的对象移动到幸存者1区。幸存者1区的作用就是用于存放幸存者0区垃圾回收处理所幸存下来的JAVA对象。

养老区（Tenure (Old) generation space）：用于保存从新生区筛选出来的JAVA对象。

垃圾回收描述：

垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收Young中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。

当一个URL被访问时，内存申请过程如下：

A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）；释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区/OLD区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

对象衰老过程：

1. young generation的内存，由一块Eden和两块Survivor Space构成。新创建的对象的内存都分配自eden。两块Survivor Space总有会一块是空闲的，用作copying collection的目标空间。Minor collection的过程就是将eden和在用survivor space中的活对象copy到空闲survivor space中。所谓survivor，也就是大部分对象在Eden出生后，根本活不过一次GC。对象在young generation里经历了一定次数的minor collection后，年纪大了，就会被移到old generation中，称为tenuring。

2. 剩余内存空间不足会触发GC，如eden空间不够了就要进行minor collection，old generation空间不够要进行major collection，permanent generation空间不足会引发Full GC。

那么如何从jstat的输出来诊断应用程序是否有内存泄露的问题呢？下面列出几个经验总结*（其实这才是本文的重点）：*

如何判断应用程序是否有内存的问题：

1. Full GC的频率，时长和效果: 如果Full GC频率较高，比如数秒一次，那么此时程序可能就已经出问题了，因为jvm在Full GC的时候是不响应外部请求的。

如果Full GC时间较长，比如持续数秒，那么此时程序可能就已经出问题了，因为jvm在Full GC的时候是不响应外部请求的。

如果Full GC之后old 区内存没有显著增加，那么程序很可能有内存泄露问题，并且不久将来可能出现outofmemory异常。

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

2. GC的频率，时长和效果: 如果JVM进行内存回收的频率非常高，比如几乎每数秒中就有一次，每次回收的时间为数秒钟；并且，通过输出还发现每次回收释放的内存非常有限，大多数对象都无法回收。这种现象很大程度上暗示着内存泄漏。(此时可以用“jmap”来获得当前的一个内存映象，看看哪些对象导致这个问题来找出原因)

如果每次GC时间特别长，比如说数十秒，那这种现象很大程度上暗示着内存泄漏。（内存中对象太多，导致遍历时间太长，有时候不好的缓存机制会造成这样的问题）

3. 常驻内存区(P)的使用率:  常驻内存如果在应用程序稳定运行较长一段时间后还在持续增长，或者在某段某几段时刻有突变，则有可能有内存问题。（当然很大可能是jvm/app server配置问题） 如果P始终停留在某个值，说明常驻内存没有突变，比较正常。