原文出處： 佔小狼
記得前段時間，同事說他們測試環境的服務器cpu使用率一直處於100%，本地又沒有什麼接口調用，爲什麼會這樣？cpu使用率居高不下，自然是有某些線程一直佔用着cpu資源，那又如何查看佔用cpu較高的線程？
當然一個正常的程序員不會寫出上述代碼，這裏只是爲了讓一個線程佔用較高的cpu資源。
top命令
在linux環境下，可以通過top命令查看各個進程的cpu使用情況，默認按cpu使用率排序
1、上圖中可以看出pid爲23344的java進程佔用了較多的cpu資源；
2、通過top -Hp 23344可以查看該進程下各個線程的cpu使用情況；
上圖中可以看出pid爲25077的線程佔了較多的cpu資源，利用jstack命令可以繼續查看該線程當前的堆棧狀態。
jstack命令
通過top命令定位到cpu佔用率較高的線程之後，繼續使用jstack pid命令查看當前java進程的堆棧狀態
jstack命令生成的thread dump信息包含了JVM中所有存活的線程，爲了分析指定線程，必須找出對應線程的調用棧，應該如何找？
在top命令中，已經獲取到了佔用cpu資源較高的線程pid，將該pid轉成16進制的值，在thread dump中每個線程都有一個nid，找到對應的nid即可；隔段時間再執行一次stack命令獲取thread dump，區分兩份dump是否有差別，在nid=0x246c的線程調用棧中，發現該線程一直在執行JstackCase類第33行的calculate方法，得到這個信息，就可以檢查對應的代碼是否有問題。
通過thread dump分析線程狀態
除了上述的分析，大多數情況下會基於thead dump分析當前各個線程的運行情況，如是否存在死鎖、是否存在一個線程長時間持有鎖不放等等。
在dump中，線程一般存在如下幾種狀態：
1、RUNNABLE，線程處於執行中
2、BLOCKED，線程被阻塞
3、WAITING，線程正在等待
實例1：多線程競爭synchronized鎖
很明顯：線程1獲取到鎖，處於RUNNABLE狀態，線程2處於BLOCK狀態
1、locked <0x000000076bf62208>說明線程1對地址爲0x000000076bf62208對象進行了加鎖；
2、waiting to lock <0x000000076bf62208> 說明線程2在等待地址爲0x000000076bf62208對象上的鎖；
3、waiting for monitor entry [0x000000001e21f000]說明線程1是通過synchronized關鍵字進入了監視器的臨界區，並處於”Entry Set”隊列，等待monitor，具體實現可以參考深入分析synchronized的JVM實現；
實例2：通過wait掛起線程
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
staticclass
Task implementsRunnable
{ @Override publicvoid
run() { synchronized(lock)
{ try{ lock.wait(); //TimeUnit.SECONDS.sleep(100000); }catch(InterruptedException
e) { e.printStackTrace(); } } }} |
dump結果
線程1和2都處於WAITING狀態
1、線程1和2都是先locked <0x000000076bf62500>，再waiting
on <0x000000076bf62500>，之所以先鎖再等同一個對象，是因爲wait方法需要先通過synchronized獲得該地址對象的monitor；
2、waiting on <0x000000076bf62500>說明線程執行了wait方法之後，釋放了monitor，進入到”Wait Set”隊列，等待其它線程執行地址爲0x000000076bf62500對象的notify方法，並喚醒自己，具體實現可以參考深入分析Object.wait/notify實現機制；
轉自http://www.importnew.com/23601.html
侵刪
@姍姍來遲