内存监控方法之——Jstat内存监控

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

    Jstat是JDK自带的一个轻量级小工具，全称是“Java Virtual Machine statistics monitoringtool”。它是一个极强的监视VM内存工具，可以用来监视VM内存内的各种堆和非堆的大小，以及内存使用量。

   Jstat位于java的bin目录下，主要是利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，同时也包括了对Heapsize、垃圾回收状况的监控。

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

 

    1. 语法结构：

    Usage:jstat -help|-options

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

    参数解释：

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

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

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

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

    2.输出格式：

   S0    S1    E     O     P    YGC    YGCT   FGC   FGCT    GCT

   参数解释：

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

    3.实例

（1）实例1：

[root@localhost bin]# jstat -gcutil 25444

  S0      S1     E      O       P     YGC    YGCT   FGC   FGCT     GCT

 11.63  0.00   56.46 66.92   98.49 162     0.248       6     0.331     0.579

 其中，25444是java的进程号

（2）实例2：

[root@localhost bin]# jstat -gcutil 25444 1000 5

S0         S1      E        O       P     YGC    YGCT   FGC   FGCT    GCT
58.34   0.00  71.44   23.88  72.08  85498  220.502   14   1.182   221.683
  0.00  33.34  35.76   24.32  72.08  85499  220.503   14   1.182   221.685
25.00   0.00   40.51  24.33  72.08  85500  220.505   14    1.182   221.687
  0.00  50.00 36.37   24.33  72.08  85501  220.507   14   1.182   221.688
  0.00  0.00   0.00     24.35  72.08  85502  220.509   14    1.182   221.691

   1）我们可以看到，5次young gc之后，垃圾内存被从Eden space区(E)放入了Oldspace区(O)，并引起了百分比的变化，导致Survivorspace使用的百分比从58.344%(S0)降到0%(S1)。有效释放了内存空间.

    2）一次full gc之后，Oldspace区(O)的内存被回收，占用的百分比会下降。

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

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

    4）CT是YGCT 和FGCT的时间总和。

附注：JVM内存管理

   JVM的内存分栈内存、堆内存、本地方法栈和方法区四部分。java通过类加载器来加载class文件，加载到内存后，会把类、方法、常变量放到堆内存中。因为java是自动进行垃圾回收的，所以放入堆内存中的东西，哪些该回收，哪些不该回收？这都需要jvm去额外的线程去进行判断。但如果对于一个大型的J2EE系统来说，当创建的对象及方法变量比较多时，即堆内存中的对象比较多，如果一个一个对象去进行循环判断是否该回收时，这样的回收机制未免太耗时了，系统的性能一定会下降，jvm为了提高jvm执行效率，采用了堆内存分区管理的机制。

   JVM把堆内存分三大块：Young GenerationSpace 新生区（也称新生代）、Tenure generationspace养老区（也称旧生代）、Permanent Space永久存储区。分区是为了进行模块化管理，管理不同的对象及变量以提高JVM的执行效率。

   对于Young Generation Space，它主要用来存储新创建的对象，内存大小会比较小，垃圾回收会比较频繁。对此区又分三个区域：一个EdenSpace和两个Survivor Space。有一个前辈对这三个区域描述的相当透彻：

• 当对象在堆创建时，将进入年轻代的EdenSpace。
• 垃圾回收器进行垃圾回收时，扫描Eden Space和ASuvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制Old Gen
• 扫描A SuvivorSpace时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个Old对象，则将其移到OldGen。
• 扫描完毕后，JVM将Eden Space和A SuvivorSpace清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和BSuvivorSpace。

    对于Tenure generationspace，它主要是用来存储那些长时间被引用的对象。因为它里面存放的是经过几次在Young GenderationSpace 进行扫描判断过仍存活的对象，内存大小会比较大，垃圾回收频率会比较小。

   对于Permanent Space永久存储区，它是用来存储一些值信息不经常变更的东东，有类定义、字节码和常量等。