JVM分析工具——jstack实践
一、不是万能的jstack
企业级的Java程序中，java程序出现性能低下甚至直接崩溃时，就不能像解决业务bug那样，从行为表现上来修复问题了。性能问题一般是jvm资源告罄的表现，需要结合jvm的相关信息，程序日志以及程序代码解决问题了。
jstack作为jvm分析工具之一，它只能做线程转储堆栈分析；而通常的性能问题，都是要结合jvm内存，gc，网络，IO等诸多信息综合分析，才能得出问题原因。有时只关注线程转储堆栈，而忽略其他，甚至会误导问题线索。
但是不可否认的是，正确分析线程转储堆栈，经验丰富的程序员直接就能把握住大方向上的问题原因。
二、最佳实践
以下是分析线程转储堆栈的一些有效实践：
- 虚拟机执行Full GC时，stop the world 会阻塞其他线程，Dump线程前，应该查看内存使用情况以及GC信息。
- 方法调用栈结合阅读代码推理，相互推导印证，往往更能发现问题。
- Bug的原因往往不会直接在调用栈上直接体现，一定要注意当前调用之前的调用情况。
如何分析
拿到一段可能有问题的线程转储堆栈，如何入手开始分析？
- 首先关注BLOCKED 状态的线程，分析调用栈
- 再关注WAITING 状态的线程，分析调用栈
- 结合经验看问题
入手总结
Deadlock：表示有死锁
Waiting on condition：等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析，比如线程正在sleep，网络读写繁忙而等待
Blocked：阻塞
Waiting on monitor entry：在等待获取锁
经验之谈
从各种性能低下或者崩溃的java程序分析实践中总结，有以下经验可供参考：
1.如果大量线程在“waiting for monitor entry”，可能是一个全局锁阻塞住了大量线程。
如果短时间内打印的 thread dump 文件反映，随着时间流逝，waiting for monitor entry 的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。
或者是因为并发太高，全局锁的情况下，waiting for monitor entry 的线程也会很多。
2.如果相同的call stack在不同时间出现在同一个线程上（tid）上， 有很大理由相信， 这段代码可能存在较多的循环或者死循环。
如果不同的时间多次dump线程，发现相同的调用栈出现在同一个线程上，那么说明这段时间跑的都是同一段代码，这种情况出现在死循环或者较多循环的代码
3.如果某个相同的call stack经常出现， 我们有80%的以上的理由确定这个代码存在性能问题（读网络的部分除外）。
.
4.如果大量线程在“waiting on condition”，并且在等待网络资源，可能是网络瓶颈的征兆
比如说作为web容器的tomcat，某一时刻其大量线程处于WAITING 状态，线程动作是 waiting on condition，调用修饰有park队列，那么说明线程正在等待网络请求的接入，而这时可以进来的网络请求又少，可能是网络瓶颈的征兆，当然也可能是这个网站压根儿没人访问哈哈。
三、Case1 log4j1造成的性能降低
最佳实践：
如果大量线程在“waiting for monitor entry”，可能是一个全局锁阻塞住了大量线程。
如果某个相同的call stack经常出现， 我们有80%的以上的理由确定这个代码存在性能问题（读网络的部分除外）。
线程及调用栈表现为，大量的线程等待进入Monitor临界区，有且仅有一个线程成功该Monitor拥有者：
大量线程处于以下状态：
"pool-1-thread-190" prio=10 tid=0x00002b853809d800 nid=0xc01 waiting for monitor entry [0x00002b84b85d5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:204)
- waiting to lock <0x00000007880579e8> (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.info(Category.java:666)
at com.jlpay.commons.rpc.thrift.server.Dispatcher.invoke(Dispatcher.java:38)
at com.jlpay.commons.rpc.thrift.server.RpcAdapterImpl.Invoke(RpcAdapterImpl.java:32)
at com.jlpay.commons.rpc.thrift.server.RpcAdapter$Processor$Invoke.getResult(RpcAdapter.java:175)
at com.jlpay.commons.rpc.thrift.server.RpcAdapter$Processor$Invoke.getResult(RpcAdapter.java:160)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:518)
at org.apache.thrift.server.Invocation.run(Invocation.java:18)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
仅有一个线程进入临界区（注意获得的锁地址与以上等待的锁地址相同）
"pool-1-thread-102" prio=10 tid=0x00002b8538053800 nid=0xba9 runnable [0x00002b84b2f71000]
java.lang.Thread.State: RUNNABLE
at java.text.DateFormat.format(DateFormat.java:336)
at org.apache.log4j.helpers.PatternParser$DatePatternConverter.convert(PatternParser.java:443)
at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)
at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked <0x0000000788057650> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
- locked <0x00000007880579e8> (a org.apache.log4j.spi.RootLogger)
原因是全局锁的存在导致性能降低，此乃log4j1的缺陷，升级日志实现即可。
四、Case2 web会话未释放导致的服务崩溃
最佳实践：
Dump线程前，先查看分析jvm内存信息
五、Case3 一个load飙高的过程分析
refer to 一个load飙高的过程分析，非常有价值
六、Case4 死锁
jstack -l <pid> 可以检测到死锁：
"Thread-1" #12 prio=5 os_prio=0 tid=0x000000001e9df000 nid=0x3a78 waiting for monitor entry [0x000000001f3cf000]
java.lang.Thread.State: BLOCKED (on object monitor)
at jstack.JStackDeadLock.fun2(JStackDeadLock.java:31)
- waiting to lock <0x000000076b881790> (a java.lang.Object)
- locked <0x000000076b8817a0> (a java.lang.Object)
at jstack.JStackDeadLock$$Lambda$2/2074407503.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
"Thread-0" #11 prio=5 os_prio=0 tid=0x000000001e9de800 nid=0x4244 waiting for monitor entry [0x000000001f2ce000]
java.lang.Thread.State: BLOCKED (on object monitor)
at jstack.JStackDeadLock.fun1(JStackDeadLock.java:21)
- waiting to lock <0x000000076b8817a0> (a java.lang.Object)
- locked <0x000000076b881790> (a java.lang.Object)
at jstack.JStackDeadLock$$Lambda$1/558638686.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x0000000002c3a758 (object 0x000000076b881790, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x000000001e9ed038 (object 0x000000076b8817a0, a java.lang.Object),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at jstack.JStackDeadLock.fun2(JStackDeadLock.java:31)
- waiting to lock <0x000000076b881790> (a java.lang.Object)
- locked <0x000000076b8817a0> (a java.lang.Object)
at jstack.JStackDeadLock$$Lambda$2/2074407503.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
"Thread-0":
at jstack.JStackDeadLock.fun1(JStackDeadLock.java:21)
- waiting to lock <0x000000076b8817a0> (a java.lang.Object)
- locked <0x000000076b881790> (a java.lang.Object)
at jstack.JStackDeadLock$$Lambda$1/558638686.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Found 1 deadlock.
可以轻易直观分析，两个锁被两个线程相互持有。
七、Case5 CPU占用高
refer to 如何使用jstack分析线程状态
案例持续加入中...
