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 可以检测到死锁：

"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分析线程状态

案例持续加入中...