JVM监控命令基本就是jps、jstack、jmap、jhat、jstat几个命令的使用就可以了
JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat等小巧的工具，本博客希望能起抛砖引玉之用，让大家能开始对JVM性能调优的常用工具有所了解。
现实企业级
Java开发中，有时候我们会碰到下面这些问题：
OutOfMemoryError，内存不足
内存泄露
线程死锁
锁争用（LockContention）
Java进程消耗CPU过高
......
这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。
A、jps(JavaVirtualMachineProcessStatusTool)
jps主要用来输出JVM中运行的进程状态信息。语法格式如下：
如果不指定hostid就默认为当前主机或服务器。
命令行参数选项说明如下：
1 | -q不输出类名、Jar名和传入main方法的参数 |
比如下面：
2 | 2458org.artifactory.standalone.main.Main/usr/ local /artifactory-2.2.5/etc/jetty.xml |
3 | 29920com.sun.tools.hat.Main-port9998/tmp/dump.dat |
4 | 3149org.apache.catalina.startup.Bootstrapstart |
5 | 30972sun.tools.jps.Jps-m-l |
6 | 8247org.apache.catalina.startup.Bootstrapstart |
7 | 25687com.sun.tools.hat.Main-port9999dump.dat |
B、jstack
jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：
2 | jstack[option]executablecore |
3 | jstack[option][server- id @]remote- hostname -or-ip |
命令行参数选项说明如下：
1 | -llonglistings，会打印出额外的锁信息，在发生死锁时可以用jstack-lpid来观察锁持有情况 |
2 | -mmixedmode，不仅会输出Java堆栈信息，还会输出C/C++堆栈信息（比如Native方法） |
jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。下面我们来一个实例找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。
第一步先找出Java进程ID，我部署在服务器上的Java应用名称为mrf-center：
1 | root@ubuntu:/ #ps-ef|grepmrf-center|grep-vgrep |
2 | root217111114:47pts/300:02:10java-jarmrf-center.jar |
得到进程ID为21711，第二步找出该进程内最耗费CPU的线程，可以使用ps-Lfppid或者ps-mppid-oTHREAD,tid,time或者top-Hppid，我这里用第三个，输出如下：
TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用
得到21742的十六进制值为54ee，下面会用到。
OK，下一步终于轮到jstack上场了，它用来输出进程21711的堆栈信息，然后根据线程ID的十六进制值grep，如下：
1 | root@ubuntu:/ #jstack21711|grep54ee |
2 | "PollIntervalRetrySchedulerThread" prio=10tid=0x00007f950043e000nid=0x54ee in Object.wait()[0x00007f94c6eda000] |
可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait()，我找了下我的代码，定位到下面的代码：
02 | getLog().info( "Thread[" +getName()+ "]isidlewaiting..." ); |
03 | schedulerThreadState=PollTaskSchedulerThreadState.IdleWaiting; |
04 | long now=System.currentTimeMillis(); |
05 | long waitTime=now+getIdleWaitTime(); |
06 | long timeUntilContinue=waitTime-now; |
10 | sigLock.wait(timeUntilContinue); |
13 | catch (InterruptedExceptionignore){ |
它是轮询任务的空闲等待代码，上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。
C、jmap（MemoryMap）和jhat（JavaHeapAnalysisTool）
jmap用来查看堆内存使用状况，一般结合jhat使用。
jmap语法格式如下：
2 | jmap[option]executablecore |
3 | jmap[option][server- id @]remote- hostname -or-ip |
如果运行在64位JVM上，可能需要指定-J-d64命令选项参数。
打印进程的类加载器和类加载器加载的持久代对象信息，输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，如下图：
使用jmap-heappid查看进程堆内存使用情况，包括使用的GC算法、堆配置参数和各代中堆内存使用情况。比如下面的例子：
01 | root@ubuntu:/ #jmap-heap21711 |
02 | AttachingtoprocessID21711,pleasewait... |
03 | Debuggerattachedsuccessfully. |
04 | Servercompilerdetected. |
07 | usingthread- local objectallocation. |
08 | ParallelGCwith4thread(s) |
13 | MaxHeapSize=2067791872(1972.0MB) |
14 | NewSize=1310720(1.25MB) |
15 | MaxNewSize=17592186044415MB |
16 | OldSize=5439488(5.1875MB) |
19 | PermSize=21757952(20.75MB) |
20 | MaxPermSize=85983232(82.0MB) |
25 | capacity=6422528(6.125MB) |
26 | used=5445552(5.1932830810546875MB) |
27 | free =976976(0.9317169189453125MB) |
30 | capacity=131072(0.125MB) |
35 | capacity=131072(0.125MB) |
40 | capacity=35258368(33.625MB) |
41 | used=4119544(3.9287033081054688MB) |
42 | free =31138824(29.69629669189453MB) |
43 | 11.683876009235595%used |
45 | capacity=52428800(50.0MB) |
46 | used=26075168(24.867218017578125MB) |
47 | free =26353632(25.132781982421875MB) |
使用jmap-histo[:live]pid查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象，如下：
01 | root@ubuntu:/ #jmap-histo:live21711|more |
03 | num #instances#bytesclassname |
04 | ---------------------------------------------- |
05 | 1:384455597736<constMethodKlass> |
06 | 2:384455237288<methodKlass> |
07 | 3:35003749504<constantPoolKlass> |
08 | 4:608583242600<symbolKlass> |
09 | 5:35002715264<instanceKlassKlass> |
10 | 6:27962131424<constantPoolCacheKlass> |
14 | 10:1225639656<methodDataKlass> |
15 | 11:14194454208java.lang.String |
16 | 12:3809396136java.lang.Class |
19 | 15:3028266464java.lang.reflect.Method |
20 | 16:280163520<objArrayKlassKlass> |
21 | 17:4355139360java.util.HashMap$Entry |
22 | 18:1869138568[Ljava.util.HashMap$Entry; |
23 | 19:244397720java.util.LinkedHashMap$Entry |
24 | 20:207282880java.lang.ref.SoftReference |
25 | 21:180771528[Ljava.lang.Object; |
26 | 22:220670592java.lang.ref.WeakReference |
27 | 23:93452304java.util.LinkedHashMap |
28 | 24:87148776java.beans.MethodDescriptor |
29 | 25:144246144java.util.concurrent.ConcurrentHashMap$HashEntry |
30 | 26:80438592java.util.HashMap |
31 | 27:94837920java.util.concurrent.ConcurrentHashMap$Segment |
32 | 28:162135696[Ljava.lang.Class; |
33 | 29:131334880[Ljava.lang.String; |
34 | 30:139633504java.util.LinkedList$Entry |
35 | 31:46233264java.lang.reflect.Field |
36 | 32:102432768java.util.Hashtable$Entry |
37 | 33:94831440[Ljava.util.concurrent.ConcurrentHashMap$HashEntry; |
classname是对象类型，说明如下：
还有一个很常用的情况是：用jmap把进程内存使用情况dump到文件中，再用jhat分析查看。jmap进行dump命令格式如下：
1 | jmap-dump: format =b, file =dumpFileName |
我一样地对上面进程ID为21711进行Dump：
1 | root@ubuntu:/ #jmap-dump:format=b,file=/tmp/dump.dat21711 |
2 | Dumpingheapto/tmp/dump.dat... |
dump出来的文件可以用MAT、VisualVM等工具查看，这里用jhat查看：
01 | root@ubuntu:/ #jhat-port9998/tmp/dump.dat |
02 | Readingfrom/tmp/dump.dat... |
03 | Dump file createdTueJan2817:46:14CST2014 |
04 | Snapshot read ,resolving... |
05 | Resolving132207objects... |
06 | Chasingreferences,expect26dots.......................... |
07 | Eliminatingduplicatereferences.......................... |
09 | StartedHTTPserveronport9998 |
然后就可以在浏览器中输入主机地址:9998查看了：
上面红线框出来的部分大家可以自己去摸索下，最后一项支持OQL（对象查询语言）。
D、jstat（JVM统计监测工具）
语法格式如下：
1 | jstat[generalOption|outputOptionsvmid[interval[s|ms][count]]] |
vmid是虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为4：
1 | root@ubuntu:/ #jstat-gc217112504 |
2 | S0CS1CS0US1UECEUOCOUPCPUYGCYGCTFGCFGCTGCT |
3 | 192.0192.064.00.06144.01854.932000.04111.655296.025472.77020.43130.2180.649 |
4 | 192.0192.064.00.06144.01972.232000.04111.655296.025472.77020.43130.2180.649 |
5 | 192.0192.064.00.06144.01972.232000.04111.655296.025472.77020.43130.2180.649 |
6 | 192.0192.064.00.06144.02109.732000.04111.655296.025472.77020.43130.2180.649 |
要明白上面各列的意义，先看JVM堆内存布局：
可以看出：
2 | 年轻代=Eden区+两个Survivor区（From和To） |
现在来解释各列含义：
1 | S0C、S1C、S0U、S1U：Survivor0/1区容量（Capacity）和使用量（Used） |
6 | FGC、FGCT：FullGC次数和FullGC耗时 |
其他JVM性能调优参考资料：
《Java虚拟机规范》
《JavaPerformance》
《TroubleShootingGuideforJavaSE6withHotSpotVM》:http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf
《EffectiveJava》
VisualVM:http://docs.oracle.com/javase/7/docs/technotes/guides/visualvm/
jConsole:http://docs.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html
MonitoringandManagingJavaSE6Applications:http://www.oracle.com/technetwork/articles/javase/monitoring-141801.html
原文路径：http://blog.csdn.net/wisgood/article/details/25343845
对应参数解释：
各种JavaThreadState第一分析法则
使用TDA工具，看到大量JavaThreadState的第一反应是：
1，线程状态为“waitingformonitorentry”：
意味着它在等待进入一个临界区，所以它在”EntrySet“队列中等待。
此时线程状态一般都是Blocked：
java.lang.Thread.State:BLOCKED(onobjectmonitor)
2，线程状态为“waitingoncondition”：
说明它在等待另一个条件的发生，来把自己唤醒，或者干脆它是调用了sleep(N)。
此时线程状态大致为以下几种：
java.lang.Thread.State:WAITING(parking)：一直等那个条件发生；
java.lang.Thread.State:TIMED_WAITING(parking或sleeping)：定时的，那个条件不到来，也将定时唤醒自己。
3，如果大量线程在“waitingformonitorentry”：
可能是一个全局锁阻塞住了大量线程。
如果短时间内打印的threaddump文件反映，随着时间流逝，waitingformonitorentry的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。
4，如果大量线程在“waitingoncondition”：
可能是它们又跑去获取第三方资源，尤其是第三方网络资源，迟迟获取不到Response，导致大量线程进入等待状态。
所以如果你发现有大量的线程都处在Waitoncondition，从线程堆栈看，正等待网络读写，这可能是一个网络瓶颈的征兆，因为网络阻塞导致线程无法执行。
线程状态为“inObject.wait()”：
说明它获得了监视器之后，又调用了java.lang.Object.wait()方法。
每个Monitor在某个时刻，只能被一个线程拥有，该线程就是“ActiveThread”，而其它线程都是“WaitingThread”，分别在两个队列“EntrySet”和“WaitSet”里面等候。在“EntrySet”中等待的线程状态是“Waitingformonitorentry”，而在“WaitSet”中等待的线程状态是“inObject.wait()”。
当线程获得了Monitor，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被synchronized的对象）的wait()方法，放弃了Monitor，进入“WaitSet”队列。
此时线程状态大致为以下几种：
java.lang.Thread.State:TIMED_WAITING(onobjectmonitor)；
java.lang.Thread.State:WAITING(onobjectmonitor)；
一般都是RMI相关线程（RMIRenewClean、GCDaemon、RMIReaper），GC线程（Finalizer），引用对象垃圾回收线程（ReferenceHandler）等系统线程处于这种状态。
图1AJavaMonitor
示范一：
下面这个线程在等待这个锁0x00000000fe7e3b50，等待进入临界区：
"RMITCPConnection(64896)-172.16.52.118"daemonprio=10tid=0x00000000405a6000nid=0x68fewaitingformonitorentry[0x00007f2be65a3000]
java.lang.Thread.State:BLOCKED(onobjectmonitor)
atcom.xyz.goods.service.impl.GoodsServiceImpl.findChanellGoodsCountWithCache(GoodsServiceImpl.java:1734)
-waitingtolock<0x00000000fe7e3b50>(ajava.lang.String)
那么谁持有这个锁呢？
是另一个先调用了findChanellGoodsCountWithCache函数的线程：
"RMITCPConnection(64878)-172.16.52.117"daemonprio=10tid=0x0000000040822000nid=0x6841runnable[0x00007f2be76b3000]
java.lang.Thread.State:RUNNABLE
atjava.net.SocketInputStream.socketRead0(NativeMethod)
atjava.net.SocketInputStream.read(SocketInputStream.java:129)
atjava.io.BufferedInputStream.fill(BufferedInputStream.java:218)
atjava.io.BufferedInputStream.read1(BufferedInputStream.java:258)
atjava.io.BufferedInputStream.read(BufferedInputStream.java:317)
-locked<0x00000000af4ed638>(ajava.io.BufferedInputStream)
atorg.bson.io.Bits.readFully(Bits.java:35)
atorg.bson.io.Bits.readFully(Bits.java:28)
atcom.mongodb.Response.<init>(Response.java:35)
atcom.mongodb.DBPort.go(DBPort.java:110)
-locked<0x00000000af442d48>(acom.mongodb.DBPort)
atcom.mongodb.DBPort.go(DBPort.java:75)
-locked<0x00000000af442d48>(acom.mongodb.DBPort)
atcom.mongodb.DBPort.call(DBPort.java:65)
atcom.mongodb.DBTCPConnector.call(DBTCPConnector.java:202)
atcom.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:296)
atcom.mongodb.DB.command(DB.java:152)
atcom.mongodb.DBCollection.getCount(DBCollection.java:760)
atcom.mongodb.DBCollection.getCount(DBCollection.java:731)
atcom.mongodb.DBCollection.count(DBCollection.java:697)
atcom.xyz.goods.manager.MongodbManager.count(MongodbManager.java:202)
atcom.xyz.goods.service.impl.GoodsServiceImpl.findChanellGoodsCount(GoodsServiceImpl.java:1787)
atcom.xyz.goods.service.impl.GoodsServiceImpl.findChanellGoodsCountWithCache(GoodsServiceImpl.java:1739)
-locked<0x00000000fe7e3b50>(ajava.lang.String)
示范二：
等待另一个条件发生来将自己唤醒：
"RMITCPConnection(idle)"daemonprio=10tid=0x00007fd50834e800nid=0x56b2waitingoncondition[0x00007fd4f1a59000]
java.lang.Thread.State:TIMED_WAITING(parking)
atsun.misc.Unsafe.park(NativeMethod)
-parkingtowaitfor<0x00000000acd84de8>(ajava.util.concurrent.SynchronousQueue$TransferStack)
atjava.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
atjava.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
atjava.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
atjava.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
atjava.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
atjava.lang.Thread.run(Thread.java:662)
1）“TIMED_WAITING(parking)”中的timed_waiting指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。
2）“waitingoncondition”需要与堆栈中的“parkingtowaitfor<0x00000000acd84de8>(ajava.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。其次，SynchronousQueue并不是一个队列，只是线程之间移交信息的机制，当我们把一个元素放入到SynchronousQueue中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。
示范三：
"RMIRenewClean-[172.16.50.182:4888]"daemonprio=10tid=0x0000000040d2c800nid=0x97einObject.wait()[0x00007f9ccafd0000]
java.lang.Thread.State:TIMED_WAITING(onobjectmonitor)
atjava.lang.Object.wait(NativeMethod)
-waitingon<0x0000000799b032d8>(ajava.lang.ref.ReferenceQueue$Lock)
atjava.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
-locked<0x0000000799b032d8>(ajava.lang.ref.ReferenceQueue$Lock)
atsun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516)
atjava.lang.Thread.run(Thread.java:662)
参考资源：
1）CUBRID，2012，HowtoAnalyzeJavaThreadDumps；
2）郑昀，2013，三个实例演示JavaTHreadDump日志分析；
原文地址：http://www.cnblogs.com/zhengyun_ustc/archive/2013/03/18/tda.html
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理
