01、線上服務器CPU飆升，如何定位到Java代碼

解決這個問題的關鍵是要找到Java代碼的位置。下面分享一下排查思路，以CentOS為例，總結為4步。

第1步，使用top命令找到占用CPU高的進程。

第2步，使用ps –mp命令找到進程下占用CPU高的線程ID。

第3步，使用printf命令將線程ID轉換成十六進制數。

第4步，使用jstack命令輸出線程運行狀態的日志信息。

下面詳細介紹每一步的操作。

第1步，在使用top命令之后，可以看到一個列表，其中包含PID（進程ID）、USER（操作用戶）、CPU占用率、內存占用率、TIME+（運行時間）、COMMAND（運行命令）等信息。一般默認按CPU占用率從上到下降序排列，如下圖所示。

我們找到COMMAND列是java的這一行，說明這個程序就是用Java編寫的。然后，用記事本記下這一行的PID，也就是進程ID。

第2步，使用ps -mp命令，輸出這個PID下面的線程運行情況列表，如下圖所示。

圖片

在這個列表中包含了幾個關鍵字段，比如CPU占用率、TID（線程ID）、TIME（運行時間）等。在這個列表中找到CPU占用最高的線程，記下TID，也就是線程ID。

前面記下的TID是一個十進制數，不能直接使用，需要轉化為十六進制數。

第3步，使用 printf 命令將TID轉換為十六進制數，如下圖所示。

圖片

這樣就得到了真正占用CPU過高的線程ID。

 第4步，使用jstack命令輸出線程的具體運行日志，如下圖所示。

圖片

jstack有3個參數，第1個參數是前面記下的 PID，之后加上 grep，緊跟著是轉成十六進制數的TID，最后加上 –A和一個數字，這個數字表示輸出日志的行數，至此就可以直接打印出具體的異常信息了。

如果日志信息比較多，異常內容比較復雜，則可以把這些異常信息輸出到一個   txt文件中，慢慢分析。只需要在 jstack命令的最后追加 txt 文件名就可以了。

jstack PID | grep TID -A60 >> error_log.txt

面試點評：從這個問題來看，面試官主要考查求職者的實操能力，以及解決問題的思路。如果求職者沒有實操過，但是知道導致 CPU 飆升的原因，并說出解決思路，那么通過面試是沒問題的。

02生產環境服務器變慢，如何診斷處理

生產環境服務器變慢主要涉及3個維度：CPU利用率、磁盤I/O效率、內存瓶頸。

1. CPU利用率

CPU利用率過高或者CPU利用率過低，都會影響程序的處理效率。CPU利用率過高，說明當前服務器要處理的指令比較多，當CPU忙不過來的時候，指令的運行效率自然就會下降，用戶的感受就是程序響應變慢了。

針對這個問題，我們可以使用top命令查詢當前系統中占用CPU過高的進程，并定位到這個進程中比較活躍的線程。再通過jstack命令打印當前虛擬機的線程快照，根據快照日志排查問題代碼。

如果CPU利用率過低，則說明程序資源使用不夠，可以增加線程數量提升程序性能。

2. 磁盤I/O效率

在程序運行過程中會直接或者間接涉及一些與磁盤I/O相關的操作，比如程序直接讀/寫磁盤或者程序依賴的第三方組件對磁盤進行持久化存儲，此時磁盤I/O效率就會對程序運行效率產生影響。

針對這種情況可以使用iostat命令查看，如果磁盤負載較高，可以針對性地進行優化。比如，借助緩存系統，減少磁盤I/O次數；用順序寫替代隨機寫入，減少尋址開銷；使用mmap替代read/write，減少內存拷貝次數。另外，磁盤I/O效率可以通過CPU與負載的非線性關系體現出來。當負載增大時，系統吞吐量不能有效增大，CPU不能線性增長，則很可能是磁盤I/O出現阻塞。

3. 內存瓶頸

內存作為一塊臨時存儲數據的組件，所有CPU運行的指令都需要從內存中去讀/寫。內存的合理使用可以減少應用和磁盤的I/O頻率，減少網絡I/O的頻率，極大地提升I/O性能。

JVM對內存的合理分配，能夠避免頻繁的YGC和FULL GC。當內存使用率較高時，可以用dump命令查出JVM堆內存，用MAT工具進行分析，查出大對象或者占用內存最多的對象，以及排查是否存在內存泄漏的問題。如果用 dump 命令查出的堆內存文件正常，則可以考慮是堆外內存被大量使用導致出現問題，此時需要借助操作系統的pmap命令查出進程的內存分配情況。如果CPU和內存使用率都很正常，那么就需要進一步開啟GC日志，分析用戶線程暫停的時間、各部分內存區域GC次數和時間等指標，這里可以借助jstat命令或可視化工具GCEasy等。如果問題出在GC上，則考慮是不是內存不足，然后根據垃圾對象的特點進行參數調優，使用更適合的垃圾收集器，用jstack命令分析各個線程的狀態。如果問題比較隱蔽，則考慮是否開啟JMX，使用 visualmv 等可視化工具進行遠程監控與分析。

面試點評：這個問題涉及的知識面比較多，如果只是站在求職者的角度來分析，則可以這樣回答。如果你沒有實際解決過類似問題，則可以說一下自己的思路，只要大體思路和方向是對的，那么在遇到類似問題的時候，可以利用網絡上的資料去逐步嘗試解決。

03線上接口負載劇增，快扛不住了，你的首選方案是什么

遇到這樣的問題，我們的第一反應應該是增加緩存。因為，增加緩存是解決系統性能問題最快速、最高效的方案，它能夠快速提升系統的線性吞吐量，效果也最為明顯。這就相當于是用空間來換取時間。曾經有人說過，緩存是解決性能問題的萬金油，哪里存在性能瓶頸，就往哪里加緩存。

但是程序都已經上線了，增加緩存還來得及嗎？因為在增加緩存時需要改代碼，所以，臨時解決方案就是增加節點。隨后，將程序緊急部署到新的節點上，在流量入口增加限流和分發。但是增加節點自然會增加成本，所以增加緩存才是最優的解決方案。

緩存的設計思想在架構設計中十分常見。比如我們每天用的操作系統，不管是Windows、Linux，還是Mac OS都有系統緩存、用戶緩存。磁盤有磁盤緩存區、CPU有CPU緩存區。再比如，在我們常用的經典框架中，也經常使用到緩存，Spring有IoC緩存，MyBatis有一級緩存、二級緩存。在架構設計中，可以說緩存無處不在。

因此，當并發量過高扛不住的時候，可以優先采用緩存來緩解負載壓力。比如將讀取頻繁的數據寫到緩存中，將動態頁面靜態化。在加上緩存之后，如果負載壓力依然過大，則再考慮增加限流策略，比如消息隊列；如果在增加限流后還是壓力過大，則再考慮增加服務器節點。

面試點評：這個問題考查的是求職者的臨場應變能力，有相關經驗的程序員回答這個問題并不困難。在回答這個問題的時候，可以分兩種情況：一種是臨時解決方案，就是加服務器；另一種就是增加緩存，但是涉及修改代碼，會增加程序不穩定的風險。