這篇文章給大家介紹java線上問題排查套路是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

成都創新互聯公司咨詢電話：028-86922220，為您提供成都網站建設網頁設計及定制高端網站建設服務，成都創新互聯公司網頁制作領域十多年，包括門窗定制等多個方面擁有豐富的網站維護經驗，選擇成都創新互聯公司，為網站錦上添花！

tags: java, troubleshooting, monitor

一句話概括：java應用線上問題如CPU過高，內存溢出，IO過高等問題如何排查，本文為你詳細講述。

1 引言

java應用上線運行后，免不了會有各種問題，總的來說問題會分為四大類：

• （1）CPU相關問題

• （2）內存相關問題

• （3）磁盤及IO相關問題

• （4）業務代碼問題。

針對這些問題，線上如何進行監測與問題排查，是一個java開發人員的必要技能。下面將結合前面提到的java命令行工具，對這幾個問題的排查套路進行說明。

2 CPU問題排查套路

如果發現系統變慢變卡，應用響應變慢，首先要查的就是CPU使用情況，一般是進程占用CPU過高，因此需要監測CPU的占用情況，而java應用中與CPU相關的主要是線程的運行，因此具體到java應用，需要監測線程的運行狀態，對應就是命令行工具jstack。因此，總結CPU占用過高問題可按下面套路：

# (1) 查詢CPU占用高的進程ID(PID)
top -c

# (2) 了解此進程的啟動參數
ps -ef|grep  PID
或者
jinfo -flags PID

# (3) 打印線程堆棧信息并輸出文件
jstack -l PID > PID.dump

# (4) 根據進程查找線程ID（TID）
top -H -p PID

# (5) 獲取TID的16進制數
printf "%x\n" TID

# (6) 結合TID和線程堆棧信息文件查找問題
- 可以使用文本工具直接查看
- 可以使用 grep TID -A20 PID.dump 來查看
- 需要配合線程狀態來檢查

關于jstack工具和線程狀態可查看文章《java應用監測(3)-這些命令行工具你掌握了嗎》

3 內存問題排查套路

內存問題主要是java應用在運行過程中發生OOM（out of memory），因此需要建議在java應用啟動時，添加幾個參數，包括-Xloggc:file -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/heapdump.hprof -XX:ErrorFile=logs/java_error_%p.log。這樣當發生oom時，可以從dump出來的文件來分析oom的原因。與內存問題相關的java命令行工具包括jmap,jstat，因此內存OOM問題排查套路如下：

# (1)找到java應用進程(PID)
jps -lvm
或者
top -c

# (2)了解此進程啟動參數（特別是-Xms，-Xmx等）
ps -ef|grep  PID
或者
jinfo -flags PID

# (3) 確認內存情況
jmap -heap PID

# (4) 查找占內存的大對象
jmap -histo:live PID 

# (5) dump出堆文件，以便使用工具分析
jmap -dump:file=./heap.hprof PID

# (6) 查看GC變化情況，如下每秒打印一次
jstat -gc PID 1000 

# (7) 結合日志文件出錯信息及dump出來的堆文件分析OOM和GC情況
- 內存分配小，適當調整內存
- 對象被頻繁創建，且不釋放，優化代碼
- young gc頻率太高，查看-Xmn、-XX:SurvivorRatio等參數設置是否合理

關于OOM，官方文檔有關于OOM的說明（https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html）， 主要分為以下幾大類：

• java.lang.OutOfMemoryError: Java heap space，堆的內存占用已經達到-Xmx設置的最大值，無法創建新對象，簡單的可以考慮通過調整-Xmx參數來解決。

• java.lang.OutOfMemoryError: GC Overhead limit exceeded，表示GC一直在執行且java進程運行很慢，通常會拋出此異常，java堆的分配的空間很小以至于新數據無法放到堆中。考慮調整堆大小，如果想關閉此輸出，可用參數來關閉-XX:-UseGCOverheadLimit。

• java.lang.OutOfMemoryError: Requested array size exceeds VM limit，java應用嘗試分配大于堆大小的數組，如堆大小是256M，卻要分配512M的數組，則會報錯。考慮調整堆大小或者修改代碼

• java.lang.OutOfMemoryError: Metaspace，當類元數據所需的本機內存量超過時MaxMetaSpaceSize時報出，考慮調整MaxMetaSpaceSize。

• java.lang.OutOfMemoryError: request size bytes for reason. Out of swap space?當來自本機堆的分配失敗并且本機堆可能接近耗盡時會報此錯誤，需要查看日志來處理。

• java.lang.OutOfMemoryError: Compressed class space，JVM的非堆結構中，類指針存放空間不足，考慮使用CompressedClassSpaceSize來調整。

• java.lang.OutOfMemoryError: reason stack_trace_with_native_method，JVM的本地方法區不足，在Java本機接口（JNI）或本機方法中檢測到分配失敗，需要查找對應堆棧信息來查詢。

4 磁盤及IO問題排查套路

java應用運行過程中，會涉及日志產生，對磁盤的讀寫等操作，也有可能有各種問題，如磁盤不足（日志輸出過多）、、磁盤讀寫IO比較慢、IO過于頻繁等。一般來說，可以按以下套路進行排查：

# (1) 查看磁盤容量情況
df -h

# (2) 查看文件大小和目錄大小
ls -l 或者直接ll
du -h --max-depth=1

# (3) 查看IO情況，找到IO讀寫頻繁的進程PID
iotop -d 1 # 1秒打印一次
或者
iostat -d -x -k 1 #1秒打印一次

# (4) 使用stack打印線程堆棧信息，排查IO相關代碼

# (5) 有時候若想測試磁盤的讀寫速度（特別是虛擬機），可以使用dd
# 示例：測數據卷掛載目錄的純寫速度
dd if=/dev/zero of=/數據卷目錄/test.iso bs=8k count=1000000

5 業務問題排查套路

業務問題，主要是涉及到代碼邏輯層面的，主要是查詢日志輸出，方法是否按正確的邏輯執行，因此一般的排查套路如下：

# (1) 實時日志輸出查詢
tail -fn 100 log_file

# (2) 根據日志輸出的關鍵字來定位問題
grep keyWord log_file # 關鍵字所在行
grep -C n keyWord log_file # 關鍵字所在前后n行

# (3) 日志文件使用可視化文本工具分析（notepad++，sublime，大文件查看如EmEditor）

# (4) 使用線上工具直接檢測方法的參數、返回值，異常情況等等，如Btrace，arthas等。

結合java的命令行工具和線上診斷工具，可以很方便地給java應用進行排查。

關于java線上問題排查套路是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。