java应用监测(4)-线上问题排查套路

tags: java, troubleshooting, monitor

---

一句话归纳：java应用线上问题如CPU太高，内存溢出，IO太高等问题如何排查，本文为你详细讲述。

1 引言

java应用上线运行后，免不了会有各类问题，总的来讲问题会分为四大类：

• （1）CPU相关问题
• （2）内存相关问题
• （3）磁盘及IO相关问题
• （4）业务代码问题。

针对这些问题，线上如何进行监测与问题排查，是一个java开发人员的必要技能。下面将结合前面提到的java命令行工具，对这几个问题的排查套路进行说明。

2 CPU问题排查套路

若是发现系统变慢变卡，应用响应变慢，首先要查的就是CPU使用状况，通常是进程占用CPU太高，所以须要监测CPU的占用状况，而java应用中与CPU相关的主要是线程的运行，所以具体到java应用，须要监测线程的运行状态，对应就是命令行工具jstack。所以，总结CPU占用太高问题可按下面套路：

# (1) 查询CPU占用高的进程ID(PID)
top -c
 # (2) 了解此进程的启动参数
ps -ef|grep  PID
或者
jinfo -flags PID
 # (3) 打印线程堆栈信息并输出文件
jstack -l PID > PID.dump
 # (4) 根据进程查找线程ID（TID）
top -H -p PID
 # (5) 获取TID的16进制数
printf "%x\n" TID
 # (6) 结合TID和线程堆栈信息文件查找问题
- 可使用文本工具直接查看
- 可使用 grep TID -A20 PID.dump 来查看
- 须要配合线程状态来检查

复制代码

关于jstack工具和线程状态可查看文章《java应用监测(3)-这些命令行工具你掌握了吗》

3 内存问题排查套路

内存问题主要是java应用在运行过程当中发生OOM（out of memory），所以须要建议在java应用启动时，添加几个参数，包括-Xloggc:file -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/heapdump.hprof -XX:ErrorFile=logs/java_error_%p.log。这样当发生oom时，能够从dump出来的文件来分析oom的缘由。与内存问题相关的java命令行工具包括jmap,jstat，所以内存OOM问题排查套路以下：

# (1)找到java应用进程(PID)
jps -lvm
或者
top -c
 # (2)了解此进程启动参数（特别是-Xms，-Xmx等）
ps -ef|grep  PID
或者
jinfo -flags PID
 # (3) 确认内存状况
jmap -heap PID
 # (4) 查找占内存的大对象
jmap -histo:live PID 
 # (5) dump出堆文件，以便使用工具分析
jmap -dump:file=./heap.hprof PID
 # (6) 查看GC变化状况，以下每秒打印一次
jstat -gc PID 1000 
 # (7) 结合日志文件出错信息及dump出来的堆文件分析OOM和GC状况
- 内存分配小，适当调整内存
- 对象被频繁建立，且不释放，优化代码
- young gc频率过高，查看-Xmn、-XX:SurvivorRatio等参数设置是否合理
复制代码

关于OOM，官方文档有关于OOM的说明（https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html）， 主要分为如下几大类：

• java.lang.OutOfMemoryError: Java heap space，堆的内存占用已经达到-Xmx设置的最大值，没法建立新对象，简单的能够考虑经过调整-Xmx参数来解决。
• java.lang.OutOfMemoryError: GC Overhead limit exceeded，表示GC一直在执行且java进程运行很慢，一般会抛出此异常，java堆的分配的空间很小以致于新数据没法放到堆中。考虑调整堆大小，若是想关闭此输出，可用参数来关闭-XX:-UseGCOverheadLimit。
• java.lang.OutOfMemoryError: Requested array size exceeds VM limit，java应用尝试分配大于堆大小的数组，如堆大小是256M，却要分配512M的数组，则会报错。考虑调整堆大小或者修改代码
• java.lang.OutOfMemoryError: Metaspace，当类元数据所需的本机内存量超过期MaxMetaSpaceSize时报出，考虑调整MaxMetaSpaceSize。
• java.lang.OutOfMemoryError: request size bytes for reason. Out of swap space?当来自本机堆的分配失败而且本机堆可能接近耗尽时会报此错误，须要查看日志来处理。
• java.lang.OutOfMemoryError: Compressed class space，JVM的非堆结构中，类指针存放空间不足，考虑使用CompressedClassSpaceSize来调整。
• java.lang.OutOfMemoryError: reason stack_trace_with_native_method，JVM的本地方法区不足，在Java本机接口（JNI）或本机方法中检测到分配失败，须要查找对应堆栈信息来查询。

4 磁盘及IO问题排查套路

java应用运行过程当中，会涉及日志产生，对磁盘的读写等操做，也有可能有各类问题，如磁盘不足（日志输出过多）、、磁盘读写IO比较慢、IO过于频繁等。通常来讲，能够按如下套路进行排查：

# (1) 查看磁盘容量状况
df -h
 # (2) 查看文件大小和目录大小
ls -l 或者直接ll
du -h --max-depth=1
 # (3) 查看IO状况，找到IO读写频繁的进程PID
iotop -d 1 # 1秒打印一次
或者
iostat -d -x -k 1 #1秒打印一次
 # (4) 使用stack打印线程堆栈信息，排查IO相关代码
 # (5) 有时候若想测试磁盘的读写速度（特别是虚拟机），可使用dd
# 示例：测数据卷挂载目录的纯写速度
dd if=/dev/zero of=/数据卷目录/test.iso bs=8k count=1000000

复制代码

5 业务问题排查套路

业务问题，主要是涉及到代码逻辑层面的，主要是查询日志输出，方法是否按正确的逻辑执行，所以通常的排查套路以下：

# (1) 实时日志输出查询
tail -fn 100 log_file
 # (2) 根据日志输出的关键字来定位问题
grep keyWord log_file # 关键字所在行
grep -C n keyWord log_file # 关键字所在先后n行
 # (3) 日志文件使用可视化文本工具分析（notepad++，sublime，大文件查看如EmEditor）
 # (4) 使用线上工具直接检测方法的参数、返回值，异常状况等等，如Btrace，arthas等。

复制代码

关于java线上问题的诊断工具包括Btrace及arthas，本系列后续会有相应的文章进行介绍。

6 总结

本文对java应用线上遇到的问题分为四大类，分别是（1）CPU相关问题，（2）内存相关问题，（3）磁盘及IO相关问题，（4）业务代码问题。针对各类问题，按照必定的套路，结合java的命令行工具和线上诊断工具，能够很方便地给java应用进行排查。但愿本文给相应的java开发人员有帮助。

参考资料

• Understand the OutOfMemoryError Exception：https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html

• 这部技术葵花宝典真的很硬核：https://mp.weixin.qq.com/s/NJPXFMgbwXWkzVLDK12Gfg

• 目前最全的Java服务问题排查套路：https://mp.weixin.qq.com/s/SuFPeWxtjHdXAcu6hkmBlA

• JDK工具参考文档：https://docs.oracle.com/javase/8/docs/technotes/tools/unix

• 示例代码地址：https://github.com/mianshenglee/my-example/tree/master/java-monitor-example

相关阅读

• java应用监测(1)-java程序员应该知道的应用监测技术:https://juejin.im/post/5d5fde94f265da03d42fae8b
• java应用监测(2)-java命令的秘密:https://juejin.im/post/5d60c8286fb9a06ada54bb87
• java应用监测(3)-这些命令行工具你掌握了吗:https://juejin.im/post/5d6207c6f265da03b46bf933