(關聯着看看這篇文章：https://blog.csdn.net/u011277123/article/details/103768939)
解決問題的能力以超高比例排名第一，這也是爲什麼很多面試過程中，面試官都喜歡問如下問題：
1、你這個項目遇到的最大挑戰是什麼？如何解決的？
2、如果線上發生了報警你回如何排查呢？
3、你有解決過什麼線上問題嗎？
4、能列舉幾個你知道的排查Linux服務器線上問題的命令嗎？
這些，都是比較常見的問題，還有一些比較具體的問題也是建議很多開發者都需要掌握的，如：
1、線上服務器Load飆高如何排查？
2、線上服務器CPU佔用率高如何排查？
3、線上服務器頻繁發生Full GC如何排查？
4、線上服務器發生死鎖如何排查？
這些問題的回答，一方面考察了面試者是否具有很強的實戰經驗，另外一方面也能體現出其解決問題的能力。
毋庸置疑，作爲開發人員來說，定位並解決問題的能力是至關重要的。因爲一旦線上發生了問題，如CPU佔用率高，如果不及時解決，很容易導致網站響應慢、服務器宕機等問題。
那麼，書歸正傳，本文我們就來簡單介紹一下，如果線上服務器發生CPU佔用率過高的問題時，應該如何排查並定位問題。
1
問題發現
本文整理自一個真實的案例，是樓主負責的業務，在一次大促之前的壓測時發現了這個問題。
在每次大促之前，我們的測試人員都會對網站進行壓力測試，這個時候會查看服務的cpu、內存、load、rt、qps等指標。
在一次壓測過程中，測試人員發現我們的某一個接口，在qps上升到500以後，CPU使用率急劇升高。
CPU利用率，又稱CPU使用率。顧名思義，CPU利用率是來描述CPU的使用情況的，表明了一段時間內CPU被佔用的情況。使用率越高，說明你的機器在這個時間上運行了很多程序，反之較少。
2
問題定位
遇到這種問題，首先是登錄到服務器，看一下具體情況。
定位進程
登錄服務器，執行top命令，查看CPU佔用情況：
$top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1893 admin 20 0 7127m 2.6g 38m S 181.7 32.6 10:20.26 java
top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源佔用狀況，類似於Windows的任務管理器。
通過以上命令，我們可以看到，進程ID爲1893的Java進程的CPU佔用率達到了181%，基本可以定位到是我們的Java應用導致整個服務器的CPU佔用率飆升。
定位線程
我們知道，Java是單進程多線程的，那麼，我們接下來看看PID=1893的這個Java進程中的各個線程的CPU使用情況，同樣是用top命令：
$top -Hp 1893
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4519 admin 20 0 7127m 2.6g 38m R 18.6 32.6 0:40.11 java
通過top -Hp 1893命令，我們可以發現，當前1893這個進程中，ID爲4519的線程佔用CPU最高。
定位代碼
通過top命令，我們目前已經定位到導致CPU使用率較高的具體線程， 那麼我麼接下來就定位下到底是哪一行代碼存在問題。
首先，我們需要把4519這個線程轉成16進制：、
$printf %x 4519
11a7
接下來，通過jstack命令，查看棧信息：
$sudo -u admin jstack 1893 |grep -A 200 11a7
"HSFBizProcessor-DEFAULT-8-thread-5" #500 daemon prio=10 os_prio=0 tid=0x00007f632314a800 nid=0x11a2 runnable [0x000000005442a000]
java.lang.Thread.State: RUNNABLE
at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:684)
at sun.misc.URLClassPath.findResource(URLClassPath.java:188)
at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
at java.lang.ClassLoader.getResource(ClassLoader.java:1093)
at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:232)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:248)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getValidationConfig(ValidationXmlParser.java:191)
at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:65)
at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:287)
at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:174)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
at com.test.common.util.BeanValidator.validate(BeanValidator.java:30)
通過以上代碼，我們可以清楚的看到，BeanValidator.java的第30行是有可能存在問題的。
3
問題解決
接下來就是通過查看代碼來解決問題了，我們發現，我們自定義了一個BeanValidator，封裝了Hibernate的Validator，然後在validate方法中，通過Validation.buildDefaultValidatorFactory().getValidator()初始化一個Validator實例，通過分析發現這個實例化的過程比較耗時。
我們重構了一下代碼，把Validator實例的初始化提到方法外，在類初始化的時候創建一次就解決了問題。
4
總結
以上，展示了一次比較完成的線上問題定位過程。主要用到的命令有:top 、printf 和 jstack
另外，線上問題排查還可以使用Alibaba開源的工具Arthas進行排查，以上問題，可以使用一下命令定位：
thread -n 3 //查看cpu佔比前三的線程
以上，本文介紹瞭如何排查線上服務器CPU使用率過高的問題，如果大家感興趣，後面可以再介紹一些關於LOAD飆高、頻繁GC等問題的排查手段。