執行緒狀態的定義
可見在 JDK 中定義的執行緒狀態總共六種，各狀態在特定條件下可以轉換，其組成了一個執行緒的生命周期，為了方便理解，對其狀態和轉換整理成了串列和狀態圖的形式，
| 狀態 | 描述 |
|---|---|
| NEW | 執行緒新建但是還沒有 start 的時候，即 new Thread() |
| RUNNABLE | 呼叫了 Thread 的 start() 方法,此時執行緒可運行，但是也有可能需要等待其他作業系統資源，比如處理器資源，當獲取到處理器資源之后，則進入 RUNNING 狀態 |
| BLOCKED | 當進入同步代碼塊時，如果需要等待獲取鎖，那么就會被阻塞進入該狀態 |
| WAITING | 由于執行了 Object.wait()、`Thread.join()、LockSupport.park() 進入了等待狀態 |
| TIMED_WAITING | 由于執行了 Thread.sleep(long)、Object.wait(long)、Thread.join(long)、LockSupport.parkNanos、LockSupport.parkUntil，進入了有限時長的等待狀態 |
| TERMINATED | 執行緒 run 方法執行結束 |
執行緒運行的幾個概念
- 臨界區
臨界區用來表示一種公共資源或者說是共享資料，可以被多個執行緒使用，但是每一次，只能有一個執行緒使用它，一旦臨界區資源被占用，其他執行緒要想使用這個資源，就必須等待，
- 死鎖
死鎖是行程死鎖的簡稱，是指多個行程回圈等待他方占有的資源而無限的僵持下去的局面，
- 活鎖
假設有兩個執行緒1、2，它們都需要資源 A/B，假設1號執行緒占有了 A 資源，2號執行緒占有了 B 資源；由于兩個執行緒都需要同時擁有這兩個資源才可以作業，為了避免死鎖，1號執行緒釋放了 A 資源占有鎖，2號執行緒釋放了 B 資源占有鎖；此時 AB 空閑，兩個執行緒又同時搶鎖，再次出現上述情況，此時發生了活鎖，
簡單類比，電梯遇到人，一個進的一個出的，對面占路，兩個人同時往一個方向讓路，來回重復，還是堵著路，
如果線上應用遇到了活鎖問題，恭喜你中獎了，這類問題比較難排查，
- 饑餓
饑餓是指某一個或者多個執行緒因為種種原因無法獲得所需要的資源，導致一直無法執行，
執行緒問題排查
在多執行緒程式中，如果出現的問題是資料例外類的問題，比較難排查需要一點點的檢查代碼，如果說是資源類的問題排查起來相對來說比較簡單，常用的命令就是 top/jps 以及 ps 定位出是哪個行程，然后通過 jstack 命令打出這個行程的全部執行緒堆疊，接下來就是分析列印的堆疊資訊了，在堆疊資訊里面列印的執行緒狀態有：
死鎖，Deadlock（重點關注）
執行中，Runnable
等待資源，Waiting on condition（重點關注）
等待獲取監視器，Waiting on monitor entry（重點關注）
暫停，Suspended
物件等待中，Object.wait() 或 TIMED_WAITING
阻塞，Blocked（重點關注）
停止，Parked
可能存在的情況有：
- 執行緒狀態為“Runnable”，
該狀態表示執行緒具備所有運行條件，在運行佇列中準備作業系統的調度，或者正在運行，
- 執行緒狀態為“waiting for monitor entry”，
意味著它在等待進入一個臨界區，所以它在“Entry Set”佇列中等待，
此時執行緒狀態一般都是 Blocked：java.lang.Thread.State: BLOCKED (on object monitor)，
- 執行緒狀態為“waiting on condition”，
說明它在等待另一個條件的發生，來把自己喚醒，或者干脆它是呼叫了 sleep(N)，此時執行緒狀態大致為以下幾種：
（1） java.lang.Thread.State: WAITING (parking)：一直等那個條件發生；
（2） java.lang.Thread.State: TIMED_WAITING (parking或sleeping)：定時的，那個條件不到來，也將定時喚醒自己，
- 如果大量執行緒在“waiting for monitor entry”，
可能是一個全域鎖阻塞住了大量執行緒，
如果短時間內列印的 thread dump 檔案反映，隨著時間流逝，waiting for monitor entry 的執行緒越來越多，沒有減少的趨勢，可能意味著某些執行緒在臨界區里呆的時間太長了，以至于越來越多新執行緒遲遲無法進入臨界區，
- 如果大量執行緒在“waiting on condition”：
可能是它們又跑去獲取第三方資源，尤其是第三方網路資源，遲遲獲取不到 Response，導致大量執行緒進入等待狀態，
所以如果你發現有大量的執行緒都處在 Wait on condition，從執行緒堆疊看，正等待網路讀寫，這可能是一個網路瓶頸的征兆，因為網路阻塞導致執行緒無法執行，
- 執行緒狀態為“in Object.wait()”：
說明它獲得了監視器之后，又呼叫了 java.lang.Object.wait() 方法，
每個 Monitor在某個時刻，只能被一個執行緒擁有，該執行緒就是 “Active Thread”，而其它執行緒都是 “Waiting Thread”，分別在兩個佇列 “ Entry Set”和 “Wait Set”里面等候，在 “Entry Set”中等待的執行緒狀態是 “Waiting for monitor entry”，而在 “Wait Set”中等待的執行緒狀態是 “in Object.wait()”，
當執行緒獲得了 Monitor，如果發現執行緒繼續運行的條件沒有滿足，它則呼叫物件（一般就是被 synchronized 的物件）的 wait() 方法，放棄了 Monitor，進入“Wait Set”佇列，
此時執行緒狀態大致為以下幾種：
java.lang.Thread.State: TIMED_WAITING (on object monitor)；
java.lang.Thread.State: WAITING (on object monitor)；
執行緒問題排查工具
cpu過高分析原因，到代碼級別
解決程序：
1，根據top命令，發現PID為2633的Java行程占用CPU高達300%，出現故障，
2，找到該行程后，如何定位具體執行緒或代碼呢，首先顯示執行緒串列,并按照CPU占用高的執行緒排序：
[root@localhost logs]# ps -mp 2633 -o THREAD,tid,time | sort -rn
顯示結果如下：
USER %CPU PRI SCNT WCHAN USER SYSTEM TID TIME
root 10.5 19 - - - - 3626 00:12:48
root 10.1 19 - - - - 3593 00:12:16
找到了耗時最高的執行緒3626，占用CPU時間有12分鐘了！
將需要的執行緒ID轉換為16進制格式：
[root@localhost logs]# printf "%x\n" 3626
e18
最后列印執行緒的堆疊資訊：
[root@localhost logs]# jstack 2633 |grep e18 -A 30
腳本 show-busy-java-threads ，自動化上面的排查程序，
一鍵輸出 javaCPU消耗高的執行緒：
https://github.com/oldratlee/useful-scripts/blob/master/docs/java.md#-show-busy-java-threads
top命令查看執行緒cpu
//間隔1秒（-d 1），輸出一次（-n 1）
top -Hp pid -d 1 -n 1
//列印System_Server行程各個執行緒的Java呼叫堆疊，根據執行緒狀態及呼叫堆疊來更進一步定位問題點
kill -3 pid
掃描二維碼，關注公眾號“猿必過”
回復 “面試題” 自行領取吧，
微信群交流討論，請添加微信號：zyhui98，備注：面試題加群
本文由猿必過 YBG 發布
禁止未經授權轉載，違者依法追究相關法律責任
如需授權可聯系：[email protected]
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/265540.html
標籤：Java
上一篇：springmvc處理模型資料