轉載:http://www.jianshu.com/p/6690f7e92f27,做了部分修改
背景
記得前段時間,同事說他們測試環境的服務器cpu使用率一直處於100%,本地又沒有什么接口調用,為什么會這樣?cpu使用率居高不下,自然是有某些線程一直占用着cpu資源,那又如何查看占用cpu較高的線程?

當然一個正常的程序員不會寫出上述代碼,這里只是為了讓一個線程占用較高的cpu資源(while循環執行邏輯會一直占用線程導致接近100%的cpu占用(如果是wait()掛起線程則不會),如果是多核如4核則一個應用程序cpu占用達到400%也是可能的)。
top命令
在linux環境下,可以通過top
命令查看各個進程的cpu使用情況,默認按cpu使用率排序

1、上圖中可以看出pid為23344的java進程占用了較多的cpu資源;
2、通過top -Hp 23344
可以查看該進程下各個線程的cpu使用情況;
(注意, top -Hp 23344后顯示如下圖,這里的PID則不是進程id了而是進程23344的各個線程id)

上圖中可以看出pid為25077的線程占了較多的cpu資源,利用jstack命令可以繼續查看該線程當前的堆棧狀態(jstack是通過查看進程詳情來查看進程里線程的狀態)。
jstack命令
通過top命令定位到cpu占用率較高的線程之后,繼續使用jstack pid(進程id)
命令查看當前java進程的堆棧狀態

(上面的nid就是線程id,不過它是十六進制的;最前面""括起來的是線程名;由下往上看打印信息才是時間順序)
jstack命令生成的thread dump信息包含了JVM中所有存活的線程,為了分析指定線程,必須找出對應線程的調用棧,應該如何找?
在top命令中,已經獲取到了占用cpu資源較高的線程pid,將該pid轉成16進制的值,在thread dump中每個線程都有一個nid,找到對應的nid即可;隔段時間再執行一次stack命令獲取thread dump,區分兩份dump是否有差別,在nid=0x246c的線程調用棧中,發現該線程一直在執行JstackCase類的內部類Task第33行的calculate方法,得到這個信息,就可以檢查對應的代碼是否有問題。
通過thread dump分析線程狀態
除了上述的分析,大多數情況下會基於thead dump分析當前各個線程的運行情況,如是否存在死鎖、是否存在一個線程長時間持有鎖不放等等。
在dump中,線程一般存在如下幾種狀態:
1、RUNNABLE,線程處於執行中
2、BLOCKED,線程被阻塞
3、WAITING,線程正在等待
4. TIMED_WAITING,這個一般是指這個線程是Timer定期執行任務,但是當前處於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]
說明線程2是通過synchronized關鍵字進入了監視器的臨界區等待,並處於"Entry Set"隊列,等待monitor,具體實現可以參考深入分析synchronized的JVM實現;
實例2:通過wait掛起線程
static class Task implements Runnable { @Override public void 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實現機制;