本文章主要演示在Windows環境，Linux環境也差不多。
一、分析CPU佔用飆高
首先寫一個Java程序，並模擬一個死循環。讓CPU使用率飆高。CPU負載過大的話，新的請求就處理不了了，這就是很多程序變慢了甚至不能訪問的原因之一。
下面是我這裏的Controller，啓動程序之後，開多個請求訪問這個方法。死循環代碼就不貼了，自己構造。我這裏模擬的一個截取字符串的死循環。
/**
* 演示死循環導致cpu使用率飆高
* */
@RequestMapping("/loop")
public List<Long> loop(){
return getPartneridsFromJson();
}
啓動程序，查看線程id，我這裏是 796
開多個請求訪問Controller方法，可以在任務管理器看到CPU不斷增高。我開了7個窗口請求。Linux下可以通過 top命令查看CPU佔用率。
現在發生了問題，開始定位問題。問題是我們手動構造的，實際生產環境肯定比這個複雜的多。
先把Java線程信息輸出到指定文件，我這裏就輸出到桌面的cpu.txt文件中，如下
某線程部分屬性說明：
jstack 796 > cpu.txt
Windows下要藉助一個工具，查看系統進程以及線程的詳細信息：
ProcessExplorer ：下載地址：ProcessExplorer
解壓，啓動，長這樣
熟悉的身影，PID爲796的Java進程。CPU佔用率最高。
在java.exe上右鍵選擇Properties，在彈出的窗口選擇Thread信息
可以看到7個CPU佔用異常高的線程。這裏的TID就是線程ID，不過是10進制的。剛剛我們jstack導出來的cpu.txt文件中的線程id是16進制的。
Linux下可以通過命令:
top -p 796 -H
查看線程的CPU佔用率。
隨便看一個，13812轉換成16進製爲：35f4，我們在cpu.txt搜一下這個線程
**可以發現，這個線程是運行中的狀態，在執行indexOf方法。是JVMTuningController.getPartneridsFromJson這個方法。**這樣就能定位到發生問題的位置了。實際生產情況要比這個複雜的多。就要慢慢分析了
二、分析線程死鎖
先構造一個死鎖方法，網上一搜一大把，我就不貼了。這是我的controller代碼
/**
* 演示死鎖 導致cpu使用率飆高
* */
@RequestMapping("/deadlock")
public String deadlock(){
deadLock();
}
程序跑起來，然後請求這個方法。
輸出線程信息到deadLock.txt
jstack 15808 > deadLock.txt
打開deadLock.txt，看到最後面
- 我的公衆號：Coding摳腚
- 偶爾發發自己最近學到的乾貨。學習路線，經驗，技術分享。技術問題交流探討。
![Coding摳腚]()
