昨天聊了性能测试指标和性能测试排除过程，主要是理论，今后几天主要讲案例。
延迟高有很多叫法，比如响应时间长、服务器反应慢、业务超时等，最根本的表现就是客户端发送请求到服务端后，服务器很长时间才给应答或者根本就没给应答。
造成延迟高（响应时间长）的原因有很多，比如：
- 服务端应用压力太大，确实处理不过来了
- 使用了不恰当的同步锁（代码级别或者其他资源锁）
- 第三方资源的不给力
- 线程池配置的不合理，线程数配置的太少导致的请求积压
- 网络原因，丢包、带宽限制、重传等
- sleep
- 调用端代码有问题导致服务器应答到达客户端后，客户端处理不及时，可能也会误认为响应时间长
分析方法
用到的工具
- jvisualvm
用于实时的监控每个方法的执行时间，统计比较精但不适合线上长时间使用。 - jstack
抓取应用当前的线程堆栈信息，分析每个线程正在执行的操作。
通过jvisualvm分析
通过jvisualvm分析能够更直观的看到每个方法的执行时间，在测试环境或者开发阶段调优非常有帮助。
首先，打开jvisualvm，jvisualvm位于jdk的bin目录下，一般配置了jdk的环境变量可以直接通过命令行输入jvisualvm打开。另外也可以通过https://visualvm.github.io/去下载直接使用。
打开后界面如下：
jvisualvm主界面
如果是本地应用，可以直接点击需要监控的进程，直接挂载上去。
如果是远程应用，需要在远程应用启动的时候，添加允许远程调试的参数。
-Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=远程机器IP 挂载成功后点击抽样器标签，抽样选择CPU，点击完后就开始监控了。
界面
监控一段时间后，一般几十秒后就可以了，点击快照抓取监控的快照，为了保险可以在运行几十秒后再抓取一次快照，为了对比确定问题。然后就可以停止监控了。
快照抓取成功后会在最右侧的标签中展示，如下图：
4.3.jpg
打开第一次的快照，选择热点标签，按总时间排序，排序后左侧的方法区就是执行时间比较长的方法。如下图所示。但是这其实不是我们想要的，你应该能看到执行时间长的都是些select、wait、sleep等，这些类似一些基本操作的方法，执行的次数比较多，还有就是设计的就是要等待的操作，所以执行的时间比较长。
4.4.jpg
比较靠谱的做法是，我们先大概过一下，如果没有明显的有问题的方法的话，而且方法也很多的话，可以根据包名过滤一下，只关注我们自己的东西，看看我们开发的方法中那些方法执行时间比较长。比如如下所示，我过滤下demo包的方法。
4.5.jpg
此时可以发现一些执行时间比较长的方法，发现以后可以通过右键在调用树中查找，确定该方法执行时间长具体是因为哪一步导致的。如下图：
4.6.jpg
现在可以发现，执行时间戳是因为本地的test调用远端的delay方法导致的，可以查看远程的delay代码优化了。
通过线程堆栈分析
生产环境中，大多数情况下没有条件通过jvisualvm的方式分析，因此只能通过执行堆栈来分析。
通过堆栈分析的话，最好是在应用出问题提交明显的情况下分析。
线程分析的根本为同一时间点同时执行某项任务的几率比较低，每次都被抓到的概率更低，如果每次都有相同的执行堆栈被抓取到，那肯定是有原因的，要么是长态任务，要么是有问题。
抓取线程堆栈
首先通过jstack命令抓取线程的执行堆栈，连续抓取3次对比用，每次间隔几秒。
jstack 进程ID > /tmp/文件名.jstack
分析
分析抓取的线程堆栈，这个比较麻烦，需要你对该应用有一定的了解，能够看到堆栈大概知道所对应的功能。
大概堆栈文件后，先大概的过一遍堆栈的信息，线程数比较多的话，可能要通过以下统计的方法过一下，要知道这么多线程中每个种类线程执行的操作的一个分布，比如多少io线程，每个线程池多少线程，多少wait线程等。
一般情况下响应时间长，在线程堆栈上的表现为有大量的线程在执行同一个操作，或者有大量线程在等同一个资源，在检查堆栈的时候我们可以重点去观察一下。
示例 - 锁等待导致的响应时间长
在遇到堆栈中有大量的BLOCKED线程的情况下，如要确定是不是用了某些不合适的同步锁。
以下是一个锁等待导致的响应时间长的堆栈信息的摘取，可以看到大量的堆栈都在waiting一个lock。
另外，线程池中没有任务，或者大量的Queue的等待的话，线程池中的线程也会是blocked或者wait的状态，但是这个是正常的，因为他就是没事可做，在等待任务。
"Thread-96" #116 prio=5 os_prio=0 tid=0x00007f4efc677800 nid=0x2ba9 waiting for monitor entry [0x00007f4e69ddc000]
java.lang.Thread.State: BLOCKED (on object monitor)
at main.java.demo.delay.Client.testDelay(Client.java:47)
- waiting to lock <0x0000000785cd4748> (a java.lang.Class for main.java.demo.delay.Client)
at main.java.demo.delay.Client$1.run(Client.java:31)
at java.lang.Thread.run(Thread.java:745)
"Thread-95" #115 prio=5 os_prio=0 tid=0x00007f4efc675800 nid=0x2ba8 waiting for monitor entry [0x00007f4e69edd000]
java.lang.Thread.State: BLOCKED (on object monitor)
at main.java.demo.delay.Client.testDelay(Client.java:47)
- waiting to lock <0x0000000785cd4748> (a java.lang.Class for main.java.demo.delay.Client)
at main.java.demo.delay.Client$1.run(Client.java:31)
at java.lang.Thread.run(Thread.java:745)
"Thread-94" #114 prio=5 os_prio=0 tid=0x00007f4efc673800 nid=0x2ba7 waiting for monitor entry [0x00007f4e69fde000]
java.lang.Thread.State: BLOCKED (on object monitor)
at main.java.demo.delay.Client.testDelay(Client.java:47)
- waiting to lock <0x0000000785cd4748> (a java.lang.Class for main.java.demo.delay.Client)
at main.java.demo.delay.Client$1.run(Client.java:31)
at java.lang.Thread.run(Thread.java:745)
"Thread-93" #113 prio=5 os_prio=0 tid=0x00007f4efc671800 nid=0x2ba6 waiting for monitor entry [0x00007f4e6a0df000]
java.lang.Thread.State: BLOCKED (on object monitor)
at main.java.demo.delay.Client.testDelay(Client.java:47)
- waiting to lock <0x0000000785cd4748> (a java.lang.Class for main.java.demo.delay.Client)
at main.java.demo.delay.Client$1.run(Client.java:31)
at java.lang.Thread.run(Thread.java:745)
"Thread-92" #112 prio=5 os_prio=0 tid=0x00007f4efc66f800 nid=0x2ba5 waiting for monitor entry [0x00007f4e6a1e0000]
java.lang.Thread.State: BLOCKED (on object monitor)
at main.java.demo.delay.Client.testDelay(Client.java:47)
- waiting to lock <0x0000000785cd4748> (a java.lang.Class for main.java.demo.delay.Client)
at main.java.demo.delay.Client$1.run(Client.java:31)
at java.lang.Thread.run(Thread.java:745)
示例 - 第三方资源响应时间长
第三方的资源有问题导致调用方响应时间长的话，和锁等待的堆栈有点类似。
- 如果请求第三方为单线程则比较简单，直接查看该线程的堆栈，如果每次抓堆栈信息都能看到在请求第三方资源的话，那说明就是有问题了，因为在响应时间很短的情况下，你不大可能每次都能抓到请求中的堆栈。
- 如果是多线程访问的话，查看线程堆栈中是不是同时有很多线程同时在执行这些操作，如果有，则需要考虑是不是第三方资源有问题了，同第一次条原因，在响应时间很短的情况下，能抓到很多线程都在执行某一个操作，不太容易。
本文由郭军营提供
2019年连续五十二天修心 土司于北京
网友评论