Java进程故障排查思路及步骤

故障场景

Java进程出现问题，一般表现出以下现象：

1. Web应用响应时间长/超时，甚至不响应
2. CPU使用率极高/低，频繁出现Full GC，甚至OutOfMemoryError

响应时间长、超时，甚至不响应，这是最直观的表现；而CPU使用率极高或极低，频繁出现Full GC，这些须要借助系统日志或者监控辅助发现。

缘由分析

针对响应时间长、超时，甚至不响应，这是一个综合性的问题致使的，可能并不单纯是应用程序自己的问题，若是后端还接了数据存储系统，除了排查应用程序自己的问题以外，还须要排查应用所依赖的第三方组件是否出现了性能瓶颈。
一般，在直观的表象背后是对应的系统指标异常，应该根据具体的系统指标进行排查，以下举例：
1.CPU使用率极高，多是应用代码出现了死循环，或者TCP链接数太高。
2.CPU使用率极低，一般是线程Hang住了，或者是出现了死锁，此时须要查看线程堆栈信息。
3.若是频繁出现Full GC，首先须要排查是否分配的堆内存空间过小，或者GC配置是否须要调优，此时须要进行内存dump分析。

经常使用工具及处理方式

1. 应用程序日志是首先排查的入口点，能够直接排查日志文件，或者从日志中心进行检索，所以要求在系统开发的时候必须设计合理的日志输出规范。
2. 针对CPU使用极高或者极低的状况，首先进行堆栈分析：jstack -l -F <pid> > stack.log，根据堆栈信息Review可能存在问题的代码逻辑。若是CPU使用率极高，一般是出现了死循环，或者TCP链接数过多，须要查看网络参数：netstat -anpt|grep <port>。
3. 若是开启了GC日志，观察到频繁出现Full GC，则考虑调整堆内存空间，甚至是JVM调优，此时首先分析堆内存dump结果：jmap -dump:live,format=b,file=heap.bin <pid>；另外，频繁Full GC，也会致使CPU使用率很高，致使没法正常响应业务请求。
4. JMX监控也经常是问题排查的辅助手段，再启动应用程序时开启远程JMX监控：-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=端口号 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false，善于使用好JDK提供的2个可用于JMX监控的工具：jconsole，jvisualvm 。
5. 能够借助第三方诊断工具进行问题定位，如：Arthas，详见：https://alibaba.github.io/arthas/index.html 。