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 。