j2se---jstat性能监控

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

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

一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。

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

执行：cd $JAVA_HOME/bin中执行jstat，注意jstat后一定要跟参数。


语法结构：

Usage: jstat -help|-options

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

参数解释：

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

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

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

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



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

实例使用1：

# 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



实例使用2：(25444是java的进程号，ps -ef | grep java)

# jstat -gcutil 25444 1000 5

S0 S1 E O P YGC YGCT FGC FGCT GCT

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

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

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

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

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

GCT 是YGCT 和FGCT的时间总和。

以上，介绍了Jstat按百分比查看gc情况的功能。其实，它还有功能，例如加载类信息统计功能、内存池信息统计功能等，那些是以绝对值的形式打印出来的，比较少用，在此就不做介绍。

# ps -ef | grep java

root 25917 1 2 23:23 pts/2 00:00:05 /usr/local/jdk1.5/bin/java -Djava.endorsed.dirs=/usr/local/jakarta-tomcat-5.0.30/common/endorsed -classpath /usr/local/jdk1.5/lib/tools.jar:/usr/local/jakarta-tomcat-5.0.30/bin/bootstrap.jar:/usr/local/jakarta-tomcat-5.0.30/bin/commons-logging-api.jar -Dcatalina.base=/usr/local/jakarta-tomcat-5.0.30 -Dcatalina.home=/usr/local/jakarta-tomcat-5.0.30 -Djava.io.tmpdir=/usr/local/jakarta-tomcat-5.0.30/temp org.apache.catalina.startup.Bootstrap start

jstat -class pid:显示加载class的数量，及所占空间等信息。

实例使用3：

# jstat -class 25917

Loaded Bytes Unloaded Bytes Time

2629 2916.8 29 24.6 0.90



jstat -compiler pid:显示VM实时编译的数量等信息。

实例使用4：

# jstat -compiler 25917

Compiled Failed Invalid Time FailedType FailedMethod

768 0 0 0.70 0



jstat –gccapacity :可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。其他的可以根据这个类推， OC是old内纯的占用量。



# jstat -gccapacity 25917

NGCMN 640.0

NGCMX 4992.0

NGC 832.0

S0C 64.0

S1C 64.0

EC 704.0

OGCMN 1408.0

OGCMX 60544.0

OGC 9504.0

OC 9504.0 OC是old内纯的占用量

PGCMN 8192.0 PGCMN显示的是最小perm的内存使用量

PGCMX 65536.0 PGCMX显示的是perm的内存最大使用量

PGC 12800.0 PGC是当前新生成的perm内存占用量

PC 12800.0 PC是但前perm内存占用量

YGC 164

FGC 6



jstat -gcnew pid: new对象的信息

# jstat -gcnew 25917

S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT

64.0 64.0 47.4 0.0 2 15 32.0 704.0 145.7 168 0.254



jstat -gcnewcapacity pid: new对象的信息及其占用量

# jstat -gcnewcapacity 25917

NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC

640.0 4992.0 832.0 64.0 448.0 448.0 64.0 4096.0 704.0 168 6



jstat -gcold pid: old对象的信息。

# jstat -gcold 25917

PC PU OC OU YGC FGC FGCT GCT

12800.0 12617.6 9504.0 6561.3 169 6 0.335 0.591



jstat -gcoldcapacity pid:old对象的信息及其占用量。

# jstat -gcoldcapacity 25917

OGCMN OGCMX OGC OC YGC FGC FGCT GCT

1408.0 60544.0 9504.0 9504.0 169 6 0.335 0.591



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

# jstat -gcpermcapacity 25917

PGCMN PGCMX PGC PC YGC FGC FGCT GCT

8192.0 65536.0 12800.0 12800.0 169 6 0.335 0.591



jstat -printcompilation pid:当前VM执行的信息。

# jstat -printcompilation -h3 25917 1000 5

每1000毫秒打印一次，一共打印5次，还可以加上-h3每三行显示一下标题。

Compiled Size Type Method

788 73 1 java/io/File <init>

788 73 1 java/io/File <init>

788 73 1 java/io/File <init>

Compiled Size Type Method

788 73 1 java/io/File <init>

788 73 1 java/io/File <init>

---------------------------------------------
二、调优
========================= 以下段落摘自网络（google或百度均可查到） =========================
JVM参数详解以及配置调优

基本概念：
　　PermGen space：全称是Permanent Generation space。就是说是永久保存的区域,用于存放Class和Meta信息，Class在被Load的时候被放入该区域。
　　Heap space：存放Instance。GC(Garbage Collection)应该不会对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。
　　Java Heap分为3个区，Young，Old和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象。
JVM有2个GC线程：
　　第一个线程负责回收Heap的Young区。
　　第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。
为什么一些程序频繁发生GC？有如下原因：
　　1） 程序内调用了System.gc()或Runtime.gc()。
　　2） 一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
　　3） Java的Heap太小，一般默认的Heap值都很小。
　　4） 频繁实例化对象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String()。
　　如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。
　　建议Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成。
　　增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。
　　Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
Stack的设定：
　　每个线程都有他自己的Stack。
　　-Xss 每个线程的Stack大小
　　Stack的大小限制着线程的数量。如果Stack过大就会导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
　　硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。
　　如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。
4种GC：

第一种为单线程GC，也是默认的GC。该GC适用于单CPU机器。
第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。
第三种为Concurrent Low Pause GC，类似于第一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。
第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。

部分JVM参数配置：
1、 heap size
a: -Xmx<n>
指定 jvm 的最大 heap 大小，如：-Xmx=2g
b: -Xms<n>
指定 jvm 的最小 heap 大小，如：-Xms=2g，高并发应用建议和-Xmx一样，防止因为内存收缩/突然增大带来的性能影响。
c: -Xmn<n>
指定 jvm 中 New Generation 的大小，如：-Xmn256m。 这个参数很影响性能，如果你的程序需要比较多的临时内存，建议设置到512M，如果用的少，尽量降低这个数值，一般来说128/256足以使用了。
d: -XX:PermSize=<n>
指定 jvm 中 Perm Generation 的最小值，如：-XX:PermSize=32m。 这个参数需要看你的实际情况，可以通过jmap 命令看看到底需要多少。
e: -XX:MaxPermSize=<n>
指定 Perm Generation 的最大值，如：-XX:MaxPermSize=64m
f: -Xss<n>
指定线程桟大小，如：-Xss128k，一般来说，webx框架下的应用需要256K。 如果你的程序有大规模的递归行为，请考虑设置到512K/1M。 这个需要全面的测试才能知道。不过，256K已经很大了。 这个参数对性能的影响比较大的。
g: -XX:NewRatio=<n>
指定 jvm 中 Old Generation heap size 与 New Generation 的比例，在使用 CMS GC 的情况下此参数失效，如:-XX:NewRatio=2
h: -XX:SurvivorRatio=<n>
指定 New Generation 中 Eden Space 与一个 Survivor Space 的 heap size 比例，-XX:SurvivorRatio=8，那么在总共New Generation为10m 的情况下，Eden Space为8m
i: -XX:MinHeapFreeRatio=<n>
指定 jvm heap在使用率小 n的情况下，heap进行收缩，Xmx==Xms 的情况下无效，如:-XX:MinHeapFreeRatio=30
j: -XX:MaxHeapFreeRatio=<n>
指定 jvm heap在使用率大于n的情况下，heap进行扩张，Xmx==Xms 的情况下无效，如:-XX:MaxHeapFreeRatio=70
k: -XX:LargePageSizeInBytes=<n>
指定 Java heap 的分页页面大小，如：-XX:LargePageSizeInBytes=128m
2: garbage collector
a: -XX:+UseParallelGC
指定在 New Generation 使用 parallel collector，并行收集，暂停app threads，同时启动多个垃圾回收thread，不能和 CMS gc 一起使用。系统吨吐量优先，但是会有较长长时间的app pause，后台系统任务可以使用此gc
b: -XX:ParallelGCThreads=<n>
指定 parallel collection 时启动的 thread 个数，默认是物理 processor 的个数。
c: -XX:+UseParallelOldGC
指定在 Old Generation 使用 parallel collector。
d: -XX:+UseParNewGC
指定在 New Generation 使用 parallel collector，是 UseParallelGC 的 gc 的升级版本，有更好的性能或者优点，可以和 CMS gc 一起使用。
e: -XX:+CMSParallelRemarkEnabled
在使用 UseParNewGC 的情况下，尽量减少 mark 的时间。
f: -XX:+UseConcMarkSweepGC
指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短，适合交互性强的系统，如 web server。
g: -XX:+UseCMSCompactAtFullCollection
在使用 concurrent gc 的情况下，防止 memory fragmention，对 live object 进行整理，使 memory 碎片减少。
h: -XX:CMSInitiatingOccupancyFraction=<n>
指示在 old generation 在使用了 n% 的比例后，启动 concurrent collector，默认值是 68，如：-XX:CMSInitiatingOccupancyFraction=70。
i: -XX:+UseCMSInitiatingOccupancyOnly
指示只有在 old generation 在使用了初始化的比例后 concurrent collector 启动收集。
3、others
a: -XX:MaxTenuringThreshold=<n>
指定一个 object 在经历了 n 次 young gc 后转移到 old generation 区，在 linux64 的 java6 下默认值是 15，此参数对于 throughput collector 无效，如：-XX:MaxTenuringThreshold=31。
b: -XX:+DisableExplicitGC
禁止 java 程序中的 full gc，如 System.gc() 的调用. 最好加上么，防止程序在代码里误用了。对性能造成冲击。
c: -XX:+UseFastAccessorMethods
get,set 方法转成本地代码。
d: -XX:+PrintGCDetails
打应垃圾收集的情况如： [GC 15610.466: [ParNew: 229689K->20221K(235968K)，0.0194460 secs] 1159829K->953935K(2070976K)，0.0196420 secs]。
e: -XX:+PrintGCTimeStamps
打应垃圾收集的时间情况，如： [Times: user=0.09 sys=0.00，real=0.02 secs]。
f: -XX:+PrintGCApplicationStoppedTime
打应垃圾收集时，系统的停顿时间，如： Total time for which application threads were stopped: 0.0225920 seconds。