目錄

• 案例
• 上下文切換開銷？
• 總結

CPU經常會成為系統性能的瓶頸，可能：

• 內存泄露導致頻繁GC，進而引起CPU使用率過高
• 代碼Bug創建了大量的線程，導致CPU頻繁上下文切換

通常所說的CPU使用率過高，隱含著一個用來比較高與低的基準值，比如

• JVM在峰值負載下的平均CPU利用率40％
• CPU使用率飆到80%就可認為不正常

JVM進程包含多個Java線程：

• 一些在等待工作
• 另一些則正在執行任務

最重要的是找到哪些線程在消耗CPU，通過線程棧定位到問題代碼
如果沒有找到個別線程的CPU使用率特別高，考慮是否線程上下文切換導致了CPU使用率過高。

案例

程序模擬CPU使用率過高 - 在線程池中創建4096個線程

在Linux環境下啟動程序：

java -Xss256k -jar demo-0.0.1-SNAPSHOT.jar

線程棧大小指定為256KB。對于測試程序來說，操作系統默認值8192KB過大，因為需要創建4096個線程。

使用top命令，我們看到Java進程的CPU使用率達到了961.6%，注意到進程ID是55790。

用更精細化的top命令查看這個Java進程中各線程使用CPU的情況：

#top -H -p 55790

可見，有個叫“scheduling-1”的線程占用了較多的CPU，達到了42.5%。因此下一步我們要找出這個線程在做什么事情。

為了找出線程在做什么，用jstack生成線程快照。
jstack輸出較大，一般將其寫入文件：

jstack 55790 > 55790.log

打開55790.log，定位到第4步中找到的名為 scheduling-1 的線程，其線程棧：

看到AbstractExecutorService#submit這個函數調用，說明它是Spring Boot啟動的周期性任務線程，向線程池中提交任務，該線程消耗了大量CPU。

上下文切換開銷？

經歷上述過程，往往已經可以定位到大量消耗CPU的線程及bug代碼，比如死循環。但對于該案例：Java進程占用的CPU是961.6%， 而“scheduling-1”線程只占用了42.5%的CPU，那其它CPU被誰占用了？

第4步用top -H -p pid命令看到的線程列表中還有許多名為“pool-1-thread-x”的線程，它們單個的CPU使用率不高，但是似乎數量比較多。你可能已經猜到，這些就是線程池中干活的線程。那剩下的CPU是不是被這些線程消耗了呢？

還需要看jstack的輸出結果，主要是看這些線程池中的線程是不是真的在干活，還是在“休息”呢？

發現這些“pool-1-thread-x”線程基本都處WAITING狀態。

• Blocking指的是一個線程因為等待臨界區的鎖（Lock或者synchronized關鍵字）而被阻塞的狀態，請你注意的是處于這個狀態的線程還沒有拿到鎖
• Waiting指的是一個線程拿到了鎖，但需等待其他線程執行某些操作。比如調用了Object.wait、Thread.join或LockSupport.park方法時，進入Waiting狀態。前提是這個線程已經拿到鎖了，并且在進入Waiting狀態前，os層面會自動釋放鎖，當等待條件滿足，外部調用了Object.notify或者LockSupport.unpark方法，線程會重新競爭鎖，成功獲得鎖后才能進入到Runnable狀態繼續執行。

回到我們的“pool-1-thread-x”線程，這些線程都處在“Waiting”狀態，從線程棧我們看到，這些線程“等待”在getTask方法調用上，線程嘗試從線程池的隊列中取任務，但是隊列為空，所以通過LockSupport.park調用進到了“Waiting”狀態。那“pool-1-thread-x”線程有多少個呢？通過下面這個命令來統計一下，結果是4096，正好跟線程池中的線程數相等。

grep -o "pool-2-thread" 55790.log | wc -l

剩下CPU到底被誰消耗了？
應該懷疑CPU的上下文切換開銷了，因為我們看到Java進程中的線程數比較多。

下面通過vmstat命令來查看一下操作系統層面的線程上下文切換活動：

cs那一欄表示線程上下文切換次數，in表示CPU中斷次數，我們發現這兩個數字非常高，基本證實了我們的猜測，線程上下文切切換消耗了大量CPU。
那具體是哪個進程導致的呢？

停止Spring Boot程序，再次運行vmstat命令，會看到in和cs都大幅下降，這就證實引起線程上下文切換開銷的Java進程正是55790。

總結

遇到CPU過高，首先定位哪個進程導致的，之后可以通過top -H -p pid命令定位到具體的線程。
其次還要通jstack查看線程的狀態，看看線程的個數或者線程的狀態，如果線程數過多，可以懷疑是線程上下文切換的開銷，我們可以通過vmstat和pidstat這兩個工具進行確認。

到此這篇關于Tomcat進程占用CPU過高的解決方法的文章就介紹到這了,更多相關Tomcat進程占用CPU過高內容請搜索以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持！