BLOCKED 和 WAITING 的區別

BLOCKED 和 WAITING 兩種狀態從結果上來看，都是線程暫停，不會占用 CPU 資源，不過還是有一些區別的

BLOCKED

等待 Monitor 鎖的阻塞線程的線程狀態，處于阻塞狀態的線程正在等待 Monitor 鎖進入 synchronized Block 或者 Method ，或者在調用 Object.wait 后重新進入同步塊/方法。簡單的說，就是線程等待 synchronized 形式的鎖時的狀態

下面這段代碼中， t1 在等待 t0 的鎖釋放（synchronized代碼塊執行完成），那么此時 t1 的狀態就是 BLOCKED

Object lock = new Object();Thread t0 = new Thread(new Runnable() { @Override public void run() {synchronized (lock){ System.out.println('t0 acquire lock success'); try {Thread.sleep(10000); } catch (InterruptedException e) {e.printStackTrace(); }} }});t0.start();Thread.sleep(100);Thread t1 = new Thread(new Runnable() { @Override public void run() {synchronized (lock){ System.out.println('t1 acquire lock success');} }});t1.start();Thread.sleep(100);System.out.println('t0 state: '+t0.getState());System.out.println('t1 state: '+t1.getState());System.out.println('done.');//outputt0 acquire lock successt0 state: TIMED_WAITINGt1 state: BLOCKEDdone.t1 acquire lock successWAITING

等待中的線程狀態，下面幾個方法的調用會導致線程進入 WAITING 狀態：

Object.wait() Thread.join() LockSupport.park()

WAITING 狀態中的線程在等待其他線程執行某些操作，比如在某個對象上調用 Object.wait() 的線程正在等待另一個線程在該對象上調用 Object.notify() 或 Object.notifyAll()。為 Thread.join() 的線程正在等待指定的線程停止。下面這段代碼中，t0 在通過 synchronized 獲取了 lock 對象的鎖之后，進行了 wait 操作，導致 t0 進入 WAITING 狀態：

Object lock = new Object();Thread t0 = new Thread(new Runnable() { @Override public void run() {synchronized (lock){ System.out.println('t0 acquire lock success'); try {lock.wait(); } catch (InterruptedException e) {e.printStackTrace(); }} }});t0.start();Thread.sleep(100);System.out.println('t0 state: '+t0.getState());System.out.println('done.');//outputt0 acquire lock successt0 state: WAITINGdone.區別

JAVA 中除了 synchronized Block/Method 的鎖，還提供了 JUC 下的鎖實現， juc.lock 下的鎖功能更強大。比如支持中斷，支持重入/非重入，公平/非公平等；但是 juc 下的鎖和 synchronized 的實現可是不太一樣的比如下面這段代碼，同樣是等待鎖，可是和synchronized等待鎖的狀態還不一樣：

ReentrantLock reentrantLock = new ReentrantLock();Thread t0 = new Thread(new Runnable() { @Override public void run() {reentrantLock.lock();System.out.println('t0 acquire lock success');try { Thread.sleep(10000);} catch (InterruptedException e) { e.printStackTrace();} }});t0.start();Thread.sleep(100);Thread t1 = new Thread(new Runnable() { @Override public void run() {reentrantLock.lock();System.out.println('t1 acquire lock success'); }});t1.start();Thread.sleep(100);System.out.println('t0 state: '+t0.getState());System.out.println('t1 state: '+t1.getState());System.out.println('done.');//outputt0 acquire lock successt0 state: TIMED_WAITINGt1 state: WAITINGdone.

同樣是加鎖，在 JUC 的鎖實現下線程狀態不太一樣，所以在觀察線程狀態時，不止是 BLOCKED 的狀態才是等待鎖， WAITING/TIMEWAITING 的狀態仍然可能是等待鎖的狀態不過 JUC 下的鎖實現，讓線程暫停/等待的核心方法還是 LockSupport.park ， jstack 對于 PARKING 形式的 WAITING 會有標注，所以在線程 stack 時還是能一眼看出來的：

//這里顯示了等待類型'Thread-0' #11 prio=5 os_prio=31 tid=0x00007f9308110000 nid=0x5c03 waiting on condition [0x0000700007fc3000] java.lang.Thread.State: WAITING (parking)//這里雖然是WAITING，但還是標注了是parking類型的at sun.misc.Unsafe.park(Native Method)

而 synchronized 形式的鎖在 jstack 下的輸出會有所區別：

//這里顯示了等待類型為monitor'Thread-1' #12 prio=5 os_prio=31 tid=0x00007f833d919800 nid=0x5a03 waiting for monitor entry [0x00007000035af000] java.lang.Thread.State: BLOCKED (on object monitor)//這里是BLOCKED狀態，同時顯示了monitor的歸屬

所以在觀察線程狀態時，需要注意Object.wait()這種WAITING和juc下鎖導致的WAITING的區別

RUNNABLE 真的是 RUNNABLE 嗎？

下面是一段 jstack 輸出的例子，該線程現在正在執行 socketRead0 方法(Native)，并且是 RUNNABLE 狀態

'RMI TCP Connection(2)-192.xxx.xx.xx' daemon prio=6 tid=0x000000000a3e8800 nid=0x158e50 runnable [0x000000000adbe000]java.lang.Thread.State: RUNNABLEat java.net.SocketInputStream.socketRead0(Native Method)at java.net.SocketInputStream.read(Unknown Source)at java.net.SocketInputStream.read(Unknown Source)at java.io.BufferedInputStream.fill(Unknown Source)at java.io.BufferedInputStream.read(Unknown Source)- locked (0x00000007ad784010) (a java.io.BufferedInputStream)at java.io.FilterInputStream.read(Unknown Source)at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)at java.lang.Thread.run(Unknown Source)

但其實這里的 RUNNABLE 只是 JAVA 層面的線程狀態，在操作系統或進程角度來看，該線程還是 WAITING 的狀態； SocketInputStream 是一個 BIO 的實現，當沒有收到數據（或者說沒有準備好可讀的數據）時會發生阻塞，可這個阻塞在JAVA線程狀態里是 RUNNABLE 的狀態，不過他并不會占用用戶態的 CPU 時間片，內核在接受到數據后會結束這個阻塞

參考

https://blog.fastthread.io/2018/09/02/threads-stuck-in-java-net-socketinputstream-socketread0/

到此這篇關于淺談JAVA 線程狀態中可能存在的一些誤區的文章就介紹到這了,更多相關JAVA 線程狀態內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！