26 面临复杂问题时的几个高级工具：它山之石，可以攻玉 前面提到了很多 JVM 的分析工具，本节里我们会再介绍几种有用的工具，大家可以在需要的时候按需使用。
OOM Killer
在前面的章节，我们简单提及过 Linux 系统上的 OOM Killer（Out Of Memory killer，OOM 终结者）。假如物理内存不足，Linux 会找出“一头比较壮的进程”来杀掉。
OOM Killer 参数调优
Java 的堆内存溢出（OOM），是指堆内存用满了，GC 没法回收导致分配不了新的对象。
而操作系统的内存溢出（OOM），则是指计算机所有的内存（物理内存 + 交换空间），都被使用满了。
这种情况下，默认配置会导致系统报警，并停止正常运行。当然，将 /proc/sys/vm/panic_on_oom 参数设置为 0 之后，则系统内核会在发生内存溢出时，自动调用 OOM Killer 功能，来杀掉最壮实的那头进程（Rogue Process，流氓进程），这样系统也许就可以继续运行了。
以下参数可以基于单个进程进行设置，以手工控制哪些进程可以被 OOM Killer 终结。这些参数位于 proc 文件系统中的 /proc/pid/ 目录下，其中 pid 是指进程的 ID。
- oom/adj：正常范围是 -16 到 15，用于计算一个进程的 OOM 评分（oom/score）。这个分值越高，该进程越有可能被 OOM Killer 给干掉。如果设置为 -17，则禁止 OOM Killer 杀死该进程。
- proc 文件系统是虚拟文件系统，某个进程被杀掉，则 /proc/pid/ 目录也就被销毁了。
OOM Killer 参数调整示例
例如进程的
pid=12884 ，root 用户执行： $ cat /proc/12884/oom_adj 0 /# 查看最终得分 $ cat /proc/12884/oom_score 161 $ cat /proc/12884/oom_score_adj 0 /# 修改分值 … $ echo -17 > /proc/12884/oom_adj $ cat /proc/12884/oom_adj -17 $ cat /proc/12884/oom_score 0 /# 查看分值修正值 $ cat /proc/12884/oom_score_adj -1000 /# 修改分值 $ echo 15 > /proc/12884/oom_adj $ cat /proc/12884/oom_adj 15 $ cat /proc/12884/oom_score 1160 $ cat /proc/12884/oom_score_adj 1000
这样配置之后，就允许某个占用了最多资源的进程，在操作系统内存不足时，也不会杀掉他，而是先去杀别的进程。
案例
我们通过以下这个案例来展示 OOM Killer。
1. 问题描述
某个 Java 应用经常挂掉，原因疑似 Java 进程被杀死。
2. 配置信息
配置如下：
- 服务器：阿里云 ECS
- IP 地址：192.168.1.52
- CPU：4 核，虚拟 CPU Intel Xeon E5-2650 2.60GHz
- 物理内存：8GB
3. 可用内存
内存不足：4 个 Java 进程，2.1+1.7+1.7+1.3=6.8G，已占用绝大部分内存。
4. 查看日志
Linux 系统的 OOM Killer 日志： sudo cat /var/log/messages | grep killer -A 2 -B 2
经排查发现，具有如下日志：
| $ sudo cat /var/log/messages | grep killer -A 2 -B 2 May 21 09:55:01 web1 systemd: Started Session 500687 of user root. May 21 09:55:02 web1 systemd: Starting Session 500687 of user root. May 21 09:55:23 web1 kernel: java invoked oom-killer: gfp_mask=0x201da，order=0，oom_score_adj=0 May 21 09:55:24 web1 kernel: java cpuset=/ mems_allowed=0 May 21 09:55:24 web1 kernel: CPU: 3 PID: 25434 Comm: java Not tainted 3.10.0-514.6.2.el7.x86_64 /#1 – May 21 12:05:01 web1 systemd: Started Session 500843 of user root. May 21 12:05:01 web1 systemd: Starting Session 500843 of user root. May 21 12:05:22 web1 kernel: jstatd invoked oom-killer: gfp_mask=0x201da，order=0，oom_score_adj=0 May 21 12:05:22 web1 kernel: jstatd cpuset=/ mems_allowed=0 May 21 12:05:23 web1 kernel: CPU: 2 PID: 10467 Comm: jstatd Not tainted 3.10.0-514.6.2.el7.x86_64 /#1 |
可以确定，确实是物理内存不足引起的。
注意：所有 Java 进程的
-Xmx 加起来，如果大于系统的剩余内存，就可能发生这种情况。
查询系统所有进程的 oom_score：
| ps -eo pid,comm,pmem –sort -rss | awk ‘{“cat /proc/”$1”/oom_score” | getline oom; print $0”\t”oom}’ |
重要提示：
如果调整过某个进程的 oom_adj 配置，那么由该进程创建的所有进程，都会继承 oom_score 分值。例如，假设某个 sshd 进程受 OOM Killer 的保护，则所有的 SSH 会话也将受到保护。这样的配置，如果发生 OOM，有可能会影响 OOM Killer 拯救系统的功能。
我们现在设想一个场景，假如我们想要随时调试跟踪线上运行的系统，需要用什么样的工具呢？下面就介绍 2 款这样的工具。
BTrace 诊断分析工具
BTrace 是基于 Java 语言的一款动态追踪工具，可用于辅助问题诊断和分析。
BTrace 项目地址： https://github.com/btraceio/btrace/
在 Wiki 页面 中有一些简单的介绍：
BTrace 基于 ASM、Java Attach API、Instruments 开发，提供很多注解。通过这些注解，可以通过 Java 代码来编写 BTrace 脚本进行只读监控，而无需深入了解 ASM 对字节码的操纵。
下面我们来实际操作一下。
BTrace 下载
找到 Release 页面，找到最新的压缩包下载：
下载完成后解压即可使用：
可以看到，bin 目录下是可执行文件，samples 目录下是脚本示例。
示例程序
我们先编写一个有入参有返回值的方法，示例如下： package demo.jvm0209; import java.util.UUID; import java.util.concurrent.TimeUnit; public class RandomSample { public static void main(String[] args) throws Exception { // int count = 10000; int seed = 0; for (int i = 0; i < count; i++) { seed = randomHash(seed); TimeUnit.SECONDS.sleep(2); } } public static int randomHash(Integer seed) { String uuid = UUID.randomUUID().toString(); int hashCode = uuid.hashCode(); System.out.println(“prev.seed=” + seed); return hashCode; } }
这个示例程序很简单，循环很多次调用某个方法，使用其他程序也是一样的。
然后运行程序，可以看到控制台每隔一段时间就有一些输出： prev.seed=1601831031 …
BTrace 提供了命令行工具，但使用起不如在 JVisualVM 中方便，下面通过 JVisualVM 中集成 BTrace 插件进行简单的演示。
JVisualVM 环境中使用 BTrace
安装 JVisualVM 插件的操作，我们在前面的章节《[JDK 内置图形界面工具]》中介绍过。
细心的同学可能已经发现，在安装 JVisualVM 的插件时，有一款插件叫做“BTrace Workbench”。安装这款插件之后，在对应的 JVM 实例上点右键，就可以进入 BTrace 的操作界面。
1. BTrace 插件安装
打开 VisualVM，选择菜单“工具–插件(G)”：
然后在插件安装界面中，找到“可用插件”：
勾选“BTrace Workbench”之后，点击“安装(I)”按钮。 如果插件不显示，请更新 JDK 到最新版。
按照引导和提示，继续安装即可。
接受协议，并点击安装。
等待安装完成：
点击“完成”按钮即可。
BTrace 插件使用
打开后默认的界面如下：
可以看到这是一个 Java 文件的样子。然后我们参考官方文档，加一些脚本进去。
BTrace 脚本示例
我们下载的 BTrace 项目中，samples 目录下有一些脚本示例。 参照这些示例，编写一个简单的 BTrace 脚本： import com.sun.btrace.annotations./; import static com.sun.btrace.BTraceUtils./; @BTrace public class TracingScript { @OnMethod( clazz = “/demo.jvm0209.//”, method = “/.//” ) // 方法进入时 public static void simple( @ProbeClassName String probeClass, @ProbeMethodName String probeMethod) { print(“entered “ + probeClass); println(“.” + probeMethod); } @OnMethod(clazz = “demo.jvm0209.RandomSample”, method = “randomHash”, location = @Location(Kind.RETURN) ) // 方法返回时 public static void onMethodReturn( @ProbeClassName String probeClass, @ProbeMethodName String probeMethod, @Duration long duration, @Return int returnValue) { print(probeClass + “.” + probeMethod); print(Strings.strcat(“(), duration=”, duration+”ns;”)); println(Strings.strcat(“ return: “, ““+returnValue)); } }
执行结果
可以看到，输出了简单的执行结果：
可以和示例程序的控制台输出比对一下。
更多示例
BTrace 提供了很多示例，照着改一改就能执行简单的监控。
Arthas 诊断分析工具
上面介绍的 BTrace 功能非常强大，但是实用限制也不少，环境问题也很多。那么有没有更好的类似工具呢？
本节我们就来介绍一下 Arthas 诊断分析工具，Arthas 项目首页： https://github.com/alibaba/arthas
Arthas 简介
Arthas（阿尔萨斯）是阿里巴巴推出了一款开源的 Java 诊断工具，深受开发者喜爱。为什么这么说呢？
- Arthas 支持 JDK 6 以及更高版本的 JDK；
- 支持 Linux/Mac/Winodws 操作系统；
- 采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，方便进行问题的定位和诊断；
- 支持 WebConsole，在某些复杂的情况下，打通 HTTP 路由就可以访问。
当我们遇到以下类似问题而束手无策时，可以使用 Arthas 来帮助我们解决：
- 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
- 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
- 遇到问题无法在线上 Debug，难道只能通过加日志再重新发布吗？
- 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！
- 是否有一个全局视角来查看系统的运行状况？
- 有什么办法可以监控到 JVM 的实时运行状态？
- 怎么快速定位应用的热点，生成火焰图？
Arthas 官方提供了基础教程和进阶教程，以及网页版的命令行模拟器，跟着执行一遍很容易了解相关的功能。
下面我们跟着教程来体验一下。
下载与安装
首先，我们来安装 Arthas： /# 准备目录 mkdir -p /usr/local/tools/arthas cd /usr/local/tools/arthas /# 执行安装脚本 curl -L https://alibaba.github.io/arthas/install.sh | sh ······
命令行启动：
/# 启动 ./as.sh -h Error: telnet is not installed. Try to use java -jar arthas-boot.jar /# 安装telnet /# yum -y install telnet /# brew install telnet /# 再次执行 ./as.sh
通过 jar 启动：
/# 进入jar目录 cd ~/.arthas/lib/3.1.7/arthas/ /# 通过jar启动 arthas java -jar arthas-boot.jar
使用示例
启动之后显示的信息大致如下图所示：
然后我们输入需要连接（Attach）的 JVM 进程，例如 1，然后回车。
如果需要退出，输入 exit 即可。
接着我们输入 help 命令查看帮助，返回的信息大致如下。 [arthas@27350]$ help NAME DESCRIPTION help Display Arthas Help keymap Display all the available keymap for the specified connection. sc Search all the classes loaded by JVM sm Search the method of classes loaded by JVM classloader Show classloader info jad Decompile class getstatic Show the static field of a class monitor Monitor method execution statistics, e.g. total/success/failure count, average rt, fail rate, etc. stack Display the stack trace for the specified class and method thread Display thread info, thread stack trace Trace the execution time of specified method invocation. watch Display the input/output parameter, return object, and thrown exception of specified method invocation tt Time Tunnel jvm Display the target JVM information ognl Execute ognl expression. mc Memory compiler, compiles java files into bytecode and class files in memory. redefine Redefine classes. @see Instrumentation/#redefineClasses(ClassDefinition…) dashboard Overview of target jvm’s thread, memory, gc, vm, tomcat info. dump Dump class byte array from JVM heapdump Heap dump options View and change various Arthas options cls Clear the screen reset Reset all the enhanced classes version Display Arthas version shutdown Shutdown Arthas server and exit the console stop Stop/Shutdown Arthas server and exit the console. Alias for shutdown. session Display current session information sysprop Display, and change the system properties. sysenv Display the system env. vmoption Display, and update the vm diagnostic options. logger Print logger info, and update the logger level history Display command history cat Concatenate and print files pwd Return working directory name mbean Display the mbean information grep grep command for pipes. profiler Async Profiler. https://github.com/jvm-profiling-tools/async-profiler
这里列出了支持的命令。如果要查看某个命令的帮助信息怎么办呢？ 可以使用
help xxx 的形式。例如：
help thread
如果查看 JVM 信息，输入命令 jvm 即可。
环境变量 sysenv：
查看线程信息，输入命令 thread：
查看某个线程的信息： [arthas@27350]$ thread 1 “main” Id=1 TIMED_WAITING at java.lang.Thread.sleep(Native Method) at java.lang.Thread.sleep(Thread.java:340) at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386) at demo.jvm0209.RandomSample.main(Unknown Source)
查看 JVM 选项 vmoption：
某些选项可以设置，这里给出了示例
vmoption PrintGCDetails true 。
查找类 sc：
反编译代码 jad：
堆内存转储 heapdump：
跟踪方法执行时间 trace：
观察方法执行 watch：
可以看到，支持条件表达式，类似于代码调试中的条件断点。 功能非常强大，并且作为一个 JVM 分析的集成环境，使用起来也比一般工具方便。更多功能请参考 Arthas 用户文档。
抽样分析器（Profilers）
下面介绍分析器（profilers，Oracle 官方翻译是“抽样器”）。
相对于前面的工具，分析器只关心 GC 中的一部分领域，本节我们也只简单介绍分析器相关的 GC 功能。 需要注意：不要认为分析器适用于所有的场景。分析器有时确实作用很大，比如检测代码中的 CPU 热点时，但某些情况使用分析器不一定是个好方案。
对 GC 调优来说也是一样的。要检测是否因为 GC 而引起延迟或吞吐量问题时，不需要使用分析器。前面提到的工具（jstat 或原生/可视化 GC 日志）就能更好更快地检测出是否存在 GC 问题.。特别是从生产环境中收集性能数据时，最好不要使用分析器，因为性能开销非常大，对正在运行的生产系统会有影响。
如果确实需要对 GC 进行优化，那么分析器就可以派上用场了，可以对 Object 的创建信息一目了然。换个角度看，如果 GC 暂停的原因不在某个内存池中，那就只会是因为创建对象太多了。所有分析器都能够跟踪对象分配（via allocation profiling），根据内存分配的轨迹，让你知道 实际驻留在内存中的是哪些对象。
分配分析能定位到在哪个地方创建了大量的对象。使用分析器辅助进行 GC 调优的好处是，能确定哪种类型的对象最占用内存，以及哪些线程创建了最多的对象。
下面我们通过实例介绍 3 种分配分析器：hprof、JVisualVM 和 AProf。实际上还有很多分析器可供选择，有商业产品，也有免费工具，但其功能和应用基本上都是类似的。
hprof
hprof 分析器内置于 JDK 之中。在各种环境下都可以使用，一般优先使用这款工具。
性能分析工具——HPROF 简介： https://github.com/cncounter/translation/blob/master/tiemao/2017⁄20/hprof/20_hprof.md
HPROF 参考文档：
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr008.html
要让 hprof 和程序一起运行，需要修改启动脚本，类似这样：
java -agentlib:hprof=heap=sites com.yourcompany.YourApplication
在程序退出时，会将分配信息 dump（转储）到工作目录下的 java.hprof.txt 文件中。使用文本编辑器打开，并搜索“SITES BEGIN”关键字，可以看到：
SITES BEGIN (ordered by live bytes) Tue Dec 8 11:16:15 2015 percent live alloc’ed stack class rank self accum bytes objs bytes objs trace name 1 64.43% 4.43% 8370336 20121 27513408 66138 302116 int[] 2 3.26% 88.49% 482976 20124 1587696 66154 302104 java.util.ArrayList 3 1.76% 88.74% 241704 20121 1587312 66138 302115 eu.plumbr.demo.largeheap.ClonableClass0006 … 部分省略 … SITES END
从以上片段可以看到，allocations 是根据每次创建的对象数量来排序的。第一行显示所有对象中有 64.43% 的对象是整型数组 (int[])，在标识为 302116 的位置创建。搜索“TRACE 302116”可以看到：
TRACE 302116: eu.plumbr.demo.largeheap.ClonableClass0006.
现在，知道有 64.43% 的对象是整数数组，在 ClonableClass0006 类的构造函数中，第 11 行的位置，接下来就可以优化代码，以减少 GC 的压力。
Java VisualVM
本章前面的第一部分，在监控 JVM 的 GC 行为工具时介绍了 JVisualVM，本节介绍其在分配分析上的应用。
JVisualVM 通过 GUI 的方式连接到正在运行的 JVM。连接上目标 JVM 之后：
- 打开“工具”–>“选项”菜单，点击 性能分析（Profiler）标签，新增配置，选择 Profiler 内存，确保勾选了“Record allocations stack traces”（记录分配栈跟踪）。
- 勾选“Settings”（设置）复选框，在内存设置标签下，修改预设配置。
- 点击“Memory”（内存）按钮开始进行内存分析。
- 让程序运行一段时间，以收集关于对象分配的足够信息。
- 单击下方的“Snapshot”（快照）按钮，可以获取收集到的快照信息。
完成上面的步骤后，可以得到类似这样的信息：
上图按照每个类被创建的对象数量多少来排序。看第一行可以知道，创建的最多的对象是 int[] 数组。鼠标右键单击这行，就可以看到这些对象都在哪些地方创建的：
与 hprof 相比，JVisualVM 更加容易使用 —— 比如上面的截图中，在一个地方就可以看到所有 int[] 的分配信息，所以多次在同一处代码进行分配的情况就很容易发现。
AProf
AProf 是一款重要的分析器，是由 Devexperts 开发的 AProf。内存分配分析器 AProf 也被打包为 Java agent 的形式。
用 AProf 分析应用程序，需要修改 JVM 启动脚本，类似这样： java -javaagent:/path-to/aprof.jar com.yourcompany.YourApplication
重启应用之后，工作目录下会生成一个 aprof.txt 文件。此文件每分钟更新一次，包含这样的信息：
======================================================================================================================== TOTAL allocation dump for 91,289 ms (0h01m31s) Allocated 1,769,670,584 bytes in 24,868,088 objects of 425 classes in 2,127 locations ======================================================================================================================== Top allocation-inducing locations with the data types allocated from them ———————————————————————————————————————— eu.plumbr.demo.largeheap.ManyTargetsGarbageProducer.newRandomClassObject: 1,423,675,776 (80.44%) bytes in 17,113,721 (68.81%) objects (avg size 83 bytes) int[]: 711,322,976 (40.19%) bytes in 1,709,911 (6.87%) objects (avg size 416 bytes) char[]: 369,550,816 (20.88%) bytes in 5,132,759 (20.63%) objects (avg size 72 bytes) java.lang.reflect.Constructor: 136,800,000 (7.73%) bytes in 1,710,000 (6.87%) objects (avg size 80 bytes) java.lang.Object[]: 41,079,872 (2.32%) bytes in 1,710,712 (6.87%) objects (avg size 24 bytes) java.lang.String: 41,063,496 (2.32%) bytes in 1,710,979 (6.88%) objects (avg size 24 bytes) java.util.ArrayList: 41,050,680 (2.31%) bytes in 1,710,445 (6.87%) objects (avg size 24 bytes) … cut for brevity …
上面的输出是按照 size 进行排序的。可以看出，80.44% 的 bytes 和 68.81% 的 objects 是在 ManyTargetsGarbageProducer.newRandomClassObject() 方法中分配的。其中，int[] 数组占用了 40.19% 的内存，是最大的一个。
继续往下看，会发现 allocation traces（分配痕迹）相关的内容，也是以 allocation size 排序的： Top allocated data types with reverse location traces ———————————————————————————————————————— int[]: 725,306,304 (40.98%) bytes in 1,954,234 (7.85%) objects (avg size 371 bytes) eu.plumbr.demo.largeheap.ClonableClass0006.: 38,357,696 (2.16%) bytes in 92,206 (0.37%) objects (avg size 416 bytes) java.lang.reflect.Constructor.newInstance: 38,357,696 (2.16%) bytes in 92,206 (0.37%) objects (avg size 416 bytes) eu.plumbr.demo.largeheap.ManyTargetsGarbageProducer.newRandomClassObject: 38,357,280 (2.16%) bytes in 92,205 (0.37%) objects (avg size 416 bytes) java.lang.reflect.Constructor.newInstance: 416 (0.00%) bytes in 1 (0.00%) objects (avg size 416 bytes) … cut for brevity …
可以看到，int[] 数组的分配，在 ClonableClass0006 构造函数中继续增大。
和其他工具一样，AProf 揭露了 分配的大小以及位置信息（allocation size and locations），从而能够快速找到最耗内存的部分。
在我们看来，AProf 是非常有用的分配分析器，因为它只专注于内存分配，所以做得最好。同时这款工具是开源免费的，资源开销也最小。
参考链接
参考资料
https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/JVM%20%e6%a0%b8%e5%bf%83%e6%8a%80%e6%9c%af%2032%20%e8%ae%b2%ef%bc%88%e5%ae%8c%ef%bc%89/26%20%e9%9d%a2%e4%b8%b4%e5%a4%8d%e6%9d%82%e9%97%ae%e9%a2%98%e6%97%b6%e7%9a%84%e5%87%a0%e4%b8%aa%e9%ab%98%e7%ba%a7%e5%b7%a5%e5%85%b7%ef%bc%9a%e5%ae%83%e5%b1%b1%e4%b9%8b%e7%9f%b3%ef%bc%8c%e5%8f%af%e4%bb%a5%e6%94%bb%e7%8e%89.md
更多学习
更多实时资讯，前沿技术，生活趣事。尽在【老马啸西风】
交流社群：[交流群信息](https://mp.weixin.qq.com/s/rkSvXxiiLGjl3S-ZOZCr0Q)
