線上故障就像埋在系統(tǒng)里的“定時炸彈”——CPU突然飆高導致服務卡頓、海量日志找不到異常、磁盤滿了直接宕機，每一種都能讓程序員頭皮發(fā)麻。
不用瞎試錯，不用靠經驗瞎猜，今天整理了4類高頻線上故障的排查套路，附實操命令，從定位到解決一步到位，收藏起來，下次故障直接抄作業(yè)！

一、CPU飆高：快速定位到具體Java線程（實操拉滿）

線上服務突然卡頓、接口響應超時，大概率是CPU飆高惹的禍。很多新手遇到這種情況，只會用top命令看一眼CPU占用，卻不知道怎么定位到具體的代碼線程，最后只能瞎折騰。

分享一套極簡排查流程，從定位進程到找到異常線程，全程只需幾行命令，新手也能快速上手??

1. 第一步：定位CPU占用最高的進程

先用top命令查看系統(tǒng)CPU使用情況，重點關注%CPU列，找到占用率最高的進程（PID）：

top

• 操作技巧：輸入top后，按「P」鍵（大寫），可以按CPU占用率從高到低排序，一眼就能找到“罪魁禍首”進程。
• 關鍵說明：如果是Java服務，進程名一般是java，記住對應的PID（比如12345），后續(xù)用得上。

2. 第二步：定位進程中CPU占用最高的線程

找到異常進程后，用top -H -p 命令，定位該進程下占用CPU最高的線程（TID）：

top -H -p 12345  # 12345替換為第一步找到的PID

• 核心作用：-H參數會將進程拆分到線程級別，按「P」鍵排序后，就能找到占用CPU最高的線程ID（TID，比如12346）。

3. 第三步：將線程ID轉換為16進制（關鍵一步）

因為Java的jstack日志中，線程ID是16進制的，所以需要將第二步找到的TID（十進制）轉換為16進制：

printf "%x\n" 12346  # 12346替換為第二步找到的TID

• 示例：假設轉換后得到的16進制線程ID是303a（注意小寫，jstack日志中是小寫）。

4. 第四步：用jstack打印日志，定位異常線程

最后用jstack命令打印該進程的線程日志，并用grep過濾出目標線程，就能找到異常代碼的堆棧信息：

jstack 12345 | grep 303a -A 20  # 12345是進程PID，303a是16進制線程ID，-A 20表示顯示后續(xù)20行

• 關鍵解讀：日志中會顯示該線程正在執(zhí)行的代碼行、方法名，順著堆棧信息找下去，就能快速定位到導致CPU飆高的具體代碼（比如死循環(huán)、頻繁GC等）。

小提示：排查完成后，記得點贊收藏，下次遇到CPU飆高，直接按這個流程來，不用再翻資料！

二、日志分析：海量日志中快速定位異常（grep組合拳）

線上服務報錯，日志文件動輒幾百M、幾個G，直接打開查找異常信息，不僅耗時，還容易看漏。

分享3個最實用的grep組合命令，幫你快速從海量日志中篩選出異常信息，效率翻倍??

1. 基礎用法：篩選包含指定關鍵詞的日志

最常用的場景：查找包含“Error”“Exception”等異常關鍵詞的日志，快速定位報錯位置：

# 篩選包含Error的日志，顯示行號
grep -n "Error" app.log

# 篩選包含Exception的日志，忽略大小寫（比如Exception、exception都能匹配）
grep -i "Exception" app.log

2. 進階用法：篩選指定時間段的日志

很多時候，我們知道故障發(fā)生的大致時間段，只需篩選該時間段內的日志，縮小查找范圍：

# 假設日志格式是 2026-02-10 14:30:00 錯誤信息，篩選14:30-14:40之間的Error日志
grep "2026-02-10 14:3[0-4]" app.log | grep "Error"

• 靈活調整：根據自己項目的日志格式，修改時間匹配規(guī)則（比如yyyy-MM-dd HH:mm:ss、MM-dd HH:mm等）。

3. 高階用法：篩選異常日志并輸出到文件

如果異常日志較多，可將篩選結果輸出到單獨的文件中，方便后續(xù)分析（避免反復執(zhí)行命令）：

# 篩選近1小時內的Exception日志，輸出到error.log文件中
grep "2026-02-10 13:" app.log | grep -i "Exception" > error.log

小技巧：如果日志是滾動日志（比如app.log.1、app.log.2），可以用grep “關鍵詞” app.log* 批量篩選所有日志文件。

三、僵尸進程：產生原因+清理方法（避免占用系統(tǒng)資源）

僵尸進程（Zombie）是線上常見的“隱形殺手”——它本身不占用CPU和內存，但會占用系統(tǒng)進程號（PID），如果大量堆積，會導致系統(tǒng)無法創(chuàng)建新進程，最終引發(fā)服務異常。

1. 先搞懂：僵尸進程是什么？怎么產生？

• 定義：僵尸進程是指子進程已經終止，但父進程沒有調用wait()或waitpid()函數回收子進程資源，導致子進程殘留的“空殼進程”。
• 核心原因：父進程異常退出、父進程邏輯缺陷（未回收子進程）、子進程執(zhí)行時間過短，父進程還沒來得及回收。

2. 第一步：查找系統(tǒng)中的僵尸進程

用ps命令篩選出僵尸進程，僵尸進程的狀態(tài)標記為「Z」：

ps -ef | grep defunct  # defunct是僵尸進程的標識
# 或者更精準的篩選
ps aux | awk '{if($8=="Z") print $0}'

• 輸出解讀：篩選結果中，STAT列顯示為Z的，就是僵尸進程，記住對應的PID和父進程PID（PPID）。

3. 第二步：清理僵尸進程（兩種方法，按需選擇）

清理僵尸進程的核心是“回收子進程資源”，優(yōu)先用溫和方法，避免影響正常服務：

方法1：重啟父進程（推薦，溫和安全）

僵尸進程是父進程未回收導致的，重啟父進程后，系統(tǒng)會自動回收其下屬的僵尸進程：

# 先查看父進程名稱（PPID是父進程ID）
ps -ef | grep 1234  # 1234是父進程PPID
# 重啟父進程（根據自己的服務啟動方式調整）
systemctl restart 服務名  # 比如systemctl restart java-service

方法2：強制殺死父進程（緊急情況使用）

如果父進程無法重啟，可強制殺死父進程，系統(tǒng)會將僵尸進程托管給init進程（PID=1），init進程會自動回收僵尸進程：

kill -9 1234  # 1234是父進程PPID，謹慎使用！

警告：強制殺死父進程會導致父進程對應的服務中斷，僅在緊急情況下使用，提前做好備份。

四、磁盤滿：inode耗盡與文件刪除后空間未釋放（坑點規(guī)避）

線上服務突然宕機，登錄服務器后發(fā)現磁盤滿了（df -h查看使用率100%），但刪除大文件后，磁盤空間還是沒釋放——這兩個坑，很多程序員都踩過。

1. 坑點1：文件刪除后，空間未釋放（原因+解決）

核心原因：

刪除的文件正在被進程占用（比如日志文件被Java進程占用），此時rm命令只是刪除了文件的目錄項，文件的實際內容還在磁盤中，空間不會釋放。

排查+解決步驟：

查找被占用的已刪除文件：

lsof | grep deleted  # 篩選出已刪除但仍被進程占用的文件

找到對應的進程（PID），重啟該進程（釋放文件占用）：

systemctl restart 服務名  # 比如重啟Java服務，釋放日志文件占用

補充說明：如果無法重啟進程，可通過echo “” > 文件名 的方式清空文件（避免刪除文件導致的占用問題）：

echo "" > app.log  # 清空日志文件，釋放空間，且不影響進程占用

2. 坑點2：inode耗盡（磁盤有空間，但無法創(chuàng)建文件）

核心原因：

磁盤的inode節(jié)點耗盡了——inode是文件的索引，每個文件對應一個inode，即使磁盤有剩余空間，inode耗盡后，也無法創(chuàng)建新文件（報錯：no space left on device）。

排查+解決步驟：

查看inode使用情況：

df -i  # 查看各分區(qū)inode使用率，Ifree列是剩余inode數量

定位inode占用最多的目錄（找到大量小文件的目錄）：

# 從根目錄開始查找，統(tǒng)計每個目錄的inode數量
for i in /*; do echo $i; find $i | wc -l; done

解決方法：刪除目錄下的大量小文件（比如日志碎片、臨時文件），釋放inode：

# 批量刪除指定目錄下的小文件（謹慎操作，確認文件可刪除）
rm -rf /tmp/*  # 比如刪除/tmp目錄下的臨時文件

預防建議：定期清理臨時文件、日志碎片，避免小文件堆積導致inode耗盡，可寫定時腳本自動清理。

五、總結

線上故障排查的核心不是“瞎試錯”，而是“找對邏輯、用對命令”——CPU飆高找線程、日志繁雜用grep、僵尸進程清父進程、磁盤滿分兩種坑點，按本文的套路來，大部分高頻故障都能在10分鐘內定位并解決。

以上就是Java線程CPU飆高、僵尸進程和磁盤滿的排查技巧的詳細內容，更多關于Java線程CPU飆高、僵尸進程和磁盤滿的資料請關注腳本之家其它相關文章！

最新評論