Java 進(jìn)程異常是生產(chǎn)環(huán)境中常見的問題，可能表現(xiàn)為 CPU / 內(nèi)存飆升、響應(yīng)緩慢、進(jìn)程崩潰等。

以下是系統(tǒng)化的排查思路和實用工具：

一、故障發(fā)現(xiàn)與初步判斷

1. 監(jiān)控系統(tǒng)告警

• 基礎(chǔ)指標(biāo)：CPU 使用率、內(nèi)存使用率、GC 頻率 / 耗時、線程數(shù)。
• 應(yīng)用指標(biāo)：請求響應(yīng)時間、吞吐量、錯誤率。

2. 日志初步分析

• 應(yīng)用日志：檢查業(yè)務(wù)日志中是否有異常堆棧（如 OOM、NullPointerException）。
• GC 日志：查看頻繁 Full GC 或長時間 STW（Stop The World）。

# 開啟GC日志
java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log YourApp

二、核心排查工具與步驟

1. 進(jìn)程狀態(tài)檢查

# 查看Java進(jìn)程ID
ps -ef | grep java

# 查看進(jìn)程資源使用情況
top -Hp <pid>  # 按CPU排序
pmap -x <pid> | sort -k3 -nr  # 按內(nèi)存占用排序

2. CPU 飆升問題

# 1. 找到CPU占用最高的Java線程
top -Hp <pid>

# 2. 將線程ID轉(zhuǎn)換為16進(jìn)制
printf "%x\n" <tid>

# 3. 導(dǎo)出線程堆棧
jstack <pid> | grep -A 30 <hex_tid>  # 查找對應(yīng)線程的堆棧

# 4. 生成線程dump文件（用于后續(xù)分析）
jstack -l <pid> > thread_dump.txt

3. 內(nèi)存泄漏排查

# 1. 查看堆內(nèi)存使用情況
jstat -gc <pid> 1000  # 每秒輸出一次GC統(tǒng)計

# 2. 生成堆轉(zhuǎn)儲文件（Heap Dump）
jmap -dump:format=b,file=heapdump.hprof <pid>

# 3. 使用MAT（Memory Analyzer Tool）分析堆轉(zhuǎn)儲
java -jar mat.jar heapdump.hprof

4. 死鎖檢測

# 直接檢測死鎖
jstack <pid> | grep -i deadlock

5. 類加載問題

# 查看類加載統(tǒng)計
jstat -class <pid>

# 導(dǎo)出類加載詳細(xì)信息
jcmd <pid> VM.class_hierarchy > class_hierarchy.txt

三、常見異常場景與解決方案

場景 1：頻繁 Full GC

可能原因：老年代空間不足、內(nèi)存泄漏、大對象頻繁分配。

排查步驟：

• 分析 GC 日志，確認(rèn) Full GC 頻率和原因。
• 使用jstat觀察堆內(nèi)存各區(qū)域變化。
• 生成堆轉(zhuǎn)儲文件，使用 MAT 分析對象占用情況。

解決方案：

# 增加堆內(nèi)存或調(diào)整新生代比例
java -Xms4g -Xmx4g -XX:NewRatio=2 YourApp

場景 2：OutOfMemoryError

錯誤類型：

• Java heap space：堆內(nèi)存不足。
• GC overhead limit exceeded：GC 耗時過長且回收內(nèi)存極少。
• PermGen space/Metaspace：方法區(qū) / 元空間溢出。

排查步驟：

# 配置OOM時自動生成堆轉(zhuǎn)儲
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdump.hprof YourApp

解決方案：

# 增大堆內(nèi)存或元空間
java -Xmx8g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m YourApp

場景 3：線程阻塞 / 死鎖

排查步驟：

• 生成線程 dump（jstack <pid>）。
• 分析線程狀態(tài)（WAITING、BLOCKED）。
• 查找持有鎖的線程和等待鎖的線程。

示例線程 dump 分析：

"Thread-1" #12 prio=5 os_prio=0 tid=0x00007f9a000a4000 nid=0x2a6e waiting for monitor entry [0x00007f99f77fd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
   at com.example.MyClass.methodB(MyClass.java:40)
   - waiting to lock <0x000000076b4a0b30> (a java.lang.Object)
   at com.example.MyClass$2.run(MyClass.java:20)

四、高級工具與技術(shù)

1. Java Mission Control (JMC)

功能：實時監(jiān)控、性能分析、飛行記錄器（Flight Recorder）。

啟動命令：

jmc &

2. Byteman

• 功能：動態(tài)注入字節(jié)碼，用于調(diào)試和性能分析。
• 示例：在方法入口 / 出口添加日志。

3. Arthas

功能： Alibaba 開源的 Java 診斷工具，支持實時監(jiān)控、熱更新等。

使用示例：

# 安裝并連接到Java進(jìn)程
curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

五、預(yù)防措施

合理配置 JVM 參數(shù)：

# 生產(chǎn)環(huán)境推薦配置
java -Xms4g -Xmx4g -Xss256k \
     -XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
     -XX:+HeapDumpOnOutOfMemoryError \
     -jar your-app.jar

編寫健壯代碼：

• 避免內(nèi)存泄漏（如靜態(tài)集合持有對象引用）。
• 合理使用線程池，避免創(chuàng)建過多線程。
• 正確處理異常，避免資源未釋放。

完善監(jiān)控系統(tǒng)：

• 集成 Prometheus + Grafana 監(jiān)控 Java 進(jìn)程。
• 設(shè)置合理的告警閾值（如 GC 時間超過 500ms 告警）。

六、故障排查流程總結(jié)

• 發(fā)現(xiàn)異常：通過監(jiān)控系統(tǒng)或用戶反饋發(fā)現(xiàn)問題。
• 初步定位：確認(rèn)異常類型（CPU 高、內(nèi)存溢出、響應(yīng)慢等）。
• 數(shù)據(jù)收集：生成線程 dump、堆轉(zhuǎn)儲、GC 日志等。
• 分析根因：使用工具分析收集的數(shù)據(jù)，找出問題根源。
• 解決方案：調(diào)整代碼、優(yōu)化配置或修復(fù) Bug。
• 驗證與預(yù)防：驗證修復(fù)效果，完善監(jiān)控和告警機(jī)制。

通過系統(tǒng)化的排查方法和工具，大多數(shù) Java 進(jìn)程異常都能快速定位并解決。關(guān)鍵在于建立完善的監(jiān)控體系和標(biāo)準(zhǔn)化的排查流程。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論