故障场景
Java进程出现问题，通常表现出如下现象：
- Web应用响应时间长/超时，甚至不响应
- CPU使用率极高/低，频繁出现Full GC，甚至OutOfMemoryError
响应时间长、超时，甚至不响应，这是最直观的表现；而CPU使用率极高或极低，频繁出现Full GC，这些需要借助系统日志或者监控辅助发现。
原因分析
针对响应时间长、超时，甚至不响应，这是一个综合性的问题导致的，可能并不单纯是应用程序本身的问题，如果后端还接了数据存储系统，除了排查应用程序本身的问题之外，还需要排查应用所依赖的第三方组件是否出现了性能瓶颈。
通常，在直观的表象背后是对应的系统指标异常，应该根据具体的系统指标进行排查，如下举例：
1.CPU使用率极高，可能是应用代码出现了死循环，或者TCP连接数过高。
2.CPU使用率极低，通常是线程Hang住了，或者是出现了死锁，此时需要查看线程堆栈信息。
3.如果频繁出现Full GC，首先需要排查是否分配的堆内存空间太小，或者GC配置是否需要调优，此时需要进行内存dump分析。
常用工具及处理方式
- 应用程序日志是首先排查的入口点，可以直接排查日志文件，或者从日志中心进行检索，因此要求在系统开发的时候必须设计合理的日志输出规范。
- 针对CPU使用极高或者极低的情况，首先进行堆栈分析：
jstack -l -F <pid> > stack.log，根据堆栈信息Review可能存在问题的代码逻辑。如果CPU使用率极高，通常是出现了死循环，或者TCP连接数过多，需要查看网络参数：netstat -anpt|grep <port>。 - 如果开启了GC日志，观察到频繁出现Full GC，则考虑调整堆内存空间，甚至是JVM调优，此时首先分析堆内存dump结果：
jmap -dump:live,format=b,file=heap.bin <pid>；另外，频繁Full GC，也会导致CPU使用率很高，导致无法正常响应业务请求。 - 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 。 - 可以借助第三方诊断工具进行问题定位，如：Arthas，详见：https://alibaba.github.io/arthas/index.html 。