本篇內容主要講解“ BLOCKED和WAITING的區(qū)別是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“ BLOCKED和WAITING的區(qū)別是什么”吧!

10年積累的成都網(wǎng)站建設、成都做網(wǎng)站經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有渝中免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

BLOCKED 和 WAITING 的區(qū)別

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

BLOCKED

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

下面這段代碼中， t1 在等待 t0 的鎖釋放(synchronized代碼塊執(zhí)行完成)，那么此時 t1 的狀態(tài)就是 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.");  //output t0 acquire lock success t0 state: TIMED_WAITING t1 state: BLOCKED done. t1 acquire lock success

WAITING

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

• Object.wait()

• Thread.join()

• LockSupport.park()

WAITING 狀態(tài)中的線程在等待其他線程執(zhí)行某些操作，比如在某個對象上調用 Object.wait() 的線程正在等待另一個線程在該對象上調用  Object.notify() 或 Object.notifyAll()。為 Thread.join() 的線程正在等待指定的線程停止。

下面這段代碼中，t0 在通過 synchronized 獲取了 lock 對象的鎖之后，進行了 wait 操作，導致 t0 進入 WAITING  狀態(tài)：

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.");  //output t0 acquire lock success t0 state: WAITING done.

區(qū)別

JAVA 中除了 synchronized Block/Method 的鎖，還提供了 JUC 下的鎖實現(xiàn)， juc.lock  下的鎖功能更強大。比如支持中斷，支持重入/非重入，公平/非公平等;但是 juc 下的鎖和 synchronized 的實現(xiàn)可是不太一樣的

比如下面這段代碼，同樣是等待鎖，可是和synchronized等待鎖的狀態(tài)還不一樣：

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.");  //output t0 acquire lock success t0 state: TIMED_WAITING t1 state: WAITING done.

同樣是加鎖，在 JUC 的鎖實現(xiàn)下線程狀態(tài)不太一樣，所以在觀察線程狀態(tài)時，不止是 BLOCKED 的狀態(tài)才是等待鎖，  WAITING/TIMEWAITING 的狀態(tài)仍然可能是等待鎖的狀態(tài)

不過 JUC 下的鎖實現(xiàn)，讓線程暫停/等待的核心方法還是 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 下的輸出會有所區(qū)別：

//這里顯示了等待類型為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狀態(tài)，同時顯示了monitor的歸屬

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

RUNNABLE 真的是 RUNNABLE 嗎?

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

"RMI TCP Connection(2)-192.xxx.xx.xx" daemon prio=6 tid=0x000000000a3e8800 nid=0x158e50 runnable [0x000000000adbe000] java.lang.Thread.State: RUNNABLE at 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)  作者：空無 鏈接：https://juejin.cn/post/6951187747189194782 來源：掘金 著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請注明出處。

但其實這里的 RUNNABLE 只是 JAVA 層面的線程狀態(tài)，在操作系統(tǒng)或進程角度來看，該線程還是 WAITING 的狀態(tài);  SocketInputStream 是一個 BIO 的實現(xiàn)，當沒有收到數(shù)據(jù)(或者說沒有準備好可讀的數(shù)據(jù))時會發(fā)生阻塞，可這個阻塞在JAVA線程狀態(tài)里是  RUNNABLE 的狀態(tài)，不過他并不會占用用戶態(tài)的 CPU 時間片，內核在接受到數(shù)據(jù)后會結束這個阻塞。

到此，相信大家對“ BLOCKED和WAITING的區(qū)別是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！