java性能分析与问题定位

发表于

今天我们来聊下生产环境排查、定位问题的工具和方法。

常用命令

jdk提供的工具类，可以用来获取java进程的内存、线程、垃圾回收等信息。

  • jstack —— 获取线程堆栈信息：
    jstack -l 7055 > store-back.jstatck

  • jmap —— 获取堆中的对象信息（类的实例等）
    jmap -dump:format=b,file=store-back.hprof 12131
    说明：需要使用eclipse MAT或者jhat工具配合，解析dump下来的内存文件。

  • OOM时自动dump方式，在java启动脚本上添加jvm命令：
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}

  • jstat —— jvm的统计信息，包含内存使用情况、垃圾回收时间、类加载等信息：
    jstat -gcutil 21891 250 7
    说明：21891 进程号； 250ms 采样间隔时间，单位毫秒； 7 采集次数

APM监控工具

通常，排查生产环境的问题，我们不会远程连到服务器，使用jstack、jmap命令获取相关信息，因为这样效率太低，而且生产环境有诸多限制。
我比较习惯使用APM(Application Performance Monitor)工具来快速定位和排查问题，比如pinpoint就是一款非常优秀的APM工具。

  • 在pinpoint首页，我们可以看到应用程序之间的拓扑图，调用次数(一般生产环境采样率为10%)，如下图。
    pinpoint首页

  • 图片右上角部分（如下图），有很多绿色的小点点，每个点代表一次http请求，横坐标为请求时间，纵坐标为该次请求的耗时（毫秒）；红色的点表示该次请求抛异常。
    请求

  • 我们可以用鼠标框住耗时最长的一部分“小点”，就可以查看每个请求的调用链(如下图)，调用链精确到某个应用的某个类的某个方法，并打印出执行的SQL语句；以及每个方法的执行耗时和百分比。
    调用链

  • 点击“inspector”按钮，可以看到每个应用(jvm进程)的内存分配情况，比如堆、永久区(java8为metaspace)占用空间，GC执行耗时，CPU消耗，每秒事务数(TPS)，活跃线程数，请求响应时间，堆外直接内存空间等等数据。一目了然，犹如上帝视角。
    此处输入图片的描述

eclipseMAT内存分析工具

还记得第一步“常用工具”中的两个命令吧：
jmap -dump:format=b,file=store-back.hprof 12131
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}
eclipseMAT就是用来分析dump下来的内存文件的。

  • 用MAT生成内存泄漏分析报告,如下图：
    内存泄漏报告

  • 通过直方图(Histogram)和支配树(Dorminator Tree)分析内存泄漏：
    直方图支配树

决策树

首先，我们通过决策树(Dorminator Tree)来分析，按package分组：
支配树

  • 找到占用内存最大的类，如下图。

浅堆(shallow heap) : 指某一个对象本身所占内存大小（也包括外部对象的”引用”，每个外部对象的”引用”为4或8个字节，分析时一般都是忽略这部分）。

保留堆(retained heap): 指对象本身和引用的“外部对象”的内存大小，但不包括“共享对象”(共享对象的概念后面会讲到)。

深堆(deep heap): 指对象本身和引用的“外部对象”的内存大小。

MAT只显示浅堆和保留堆的大小，很明显，浅堆和保留堆所占空间差距过大，就非常有可能是“内存泄漏”了。
支配树分组

  • 在这里，我们怀疑Activity对象可能泄漏内存，于是查下引用此对象的是谁(with incoming references)。
    incoming

  • 我们大概看一眼，就会发现，主要是WebAppClassLoader持有大量Activity对象的引用。
    activity对象的引用者

  • 使用合并最短根路径(GC ROOTS)方式，检查对象的引用路径,如下图。

Merge Shortest Path To GC Roots：
快速分析的一个常用功能，它能够从当前内存映像中找到一条指定对象所在的到GC Root的最短路径。

需要排除弱引用、软引用及影子引用等，一般来说这三种类型的引用都不会是造成内存泄漏的原因，
因为JVM迟早是会回收只存在这三种引用的资源的。
gcroots

  • 再次确认，要是WebAppClassLoader持有大量Activity对象的引用。
    我们通过决策树的方式分析，大概可以判断Activity对象是内存泄漏的最大嫌疑人。
    activity

直方图

下面我们再通过直方图的方式分析。

直方图首页，依然通过浅堆和保留堆来分析，发现FindShoppingCartByType对象可能导致内存泄漏。
直方图首页

  • 查看引用人是谁(with incoming references)
    直方图引用人

  • 咦，又看到熟悉的人了，Activity……
    incoming

  • 依然使用合并最短根路径(GC ROOTS)方式，检查对象的引用路径,如下图。
    gcroots

  • 根据下图，得出结论：
    主要是WebAppClassLoader持有大量Activity对象的引用；
    Activity对象持有大量FindShoppingCartByType对象的引用。

gcroots

因为本例的程序是部署在tomcat中，这就相当于是Activity对象常驻内存，无法在GC时释放。
通过阅读代码，发现Activity对象是使用static声明的变量，符合我们的推断。至此，内存泄漏问题定位到了原因，后面就是改代码啦。