開發(fā)人員的基本能力。這不，有一位小伙伴去阿里面試，第一面就遇到了關于“CPU 飆高系統(tǒng)反應慢怎么排查”的問題？當時這位小伙伴不知從何下手。

今天，我給大家分享一下我的解決思路。

CPU 是整個電腦的核心計算資源，對于一個應用進程來說，CPU 的最小執(zhí)行單元是線程。導致 CPU 飆高的原因有以下兩個：

1.CPU 上下文切換過多

對于 CPU 來說，同一時刻下每個 CPU 核心只能運行一個線程，如果有多個線程要執(zhí)行，CPU 只能通過上下文切換的方式來執(zhí)行不同的線程。上下文切換需要做兩個事情

保存運行線程的執(zhí)行狀態(tài)

讓處于等待中的線程執(zhí)行

這兩個過程需要 CPU 執(zhí)行內(nèi)核相關指令實現(xiàn)狀態(tài)保存，如果較多的上下文切換會占據(jù)大量CPU 資源，從而使得 CPU 無法去執(zhí)行用戶進程中的指令，導致響應速度下降。在 Java 中，文件 IO、網(wǎng)絡 IO、鎖等待、線程阻塞等操作都會造成線程阻塞從而觸發(fā)上下文切換。

2.CPU 資源過度消耗

也就是在程序中創(chuàng)建了大量的線程，或者有線程一直占用CPU 資源無法被釋放，比如死循環(huán)！CPU 利用率過高之后，導致應用中的線程無法獲得 CPU 的調(diào)度，從而影響程序的執(zhí)行效率！既然是這兩個問題導致的 CPU 利用率較高，于是我們可以通過 top 命令，找到CPU 利用率較高的進程，在通過 Shift+H 找到進程中 CPU 消耗過高的線程，這里有兩種情況。

CPU 利用率過高的線程一直是同一個，說明程序中存在線程長期占用 CPU 沒有釋放的情況，這種情況直接通過 jstack 獲得線程的 Dump 日志，定位到線程日志后就可以找到問題的代碼。

CPU 利用率過高的線程 ID 不斷變化，說明線程創(chuàng)建過多，需要挑選幾個線程 ID，通過 jstack 去線程 dump 日志中排查。最后有可能定位的結果是程序正常，只是在 CPU 飆高的那一刻，用戶訪問量較大，導致系統(tǒng)資源不夠。

以上就是我對這個問題的理解！從這個問題來看，面試官主要考察實操能力，以及解決問題的思路。如果你沒有實操過，但是你知道導致 CPU 飆高這個現(xiàn)象的原因，并說出你的解決思路，通過面試是沒問題的。