線程進入阻塞時，線程會不會讓出CPU？這取決于上下文切換的機制。通常，WindowsLinuxIOS會給每個線程指定的執(zhí)行時間。如果時間到了，就會出現(xiàn)計時器中斷信號，線程將被動地失去使用CPU的權(quán)利。

線程進入阻塞時，線程會不會讓出CPU？

這取決于上下文切換的機制。通常，WindowsLinuxIOS會給每個線程指定的執(zhí)行時間。如果時間到了，就會出現(xiàn)計時器中斷信號，線程將被動地失去使用CPU的權(quán)利。然而，一些簡單的嵌入式系統(tǒng)沒有這種機制。上下文切換通常要求線程放棄CPU的使用權(quán)，并將其交給內(nèi)核。如果當前線程此時被阻塞，將導致死循環(huán)。在這個時候，我們應(yīng)該主動調(diào)用函數(shù)，比如重新調(diào)度或者向內(nèi)核發(fā)送信號。當然，帶定時器的系統(tǒng)也可以調(diào)用這些函數(shù)，要求當前線程提前放棄CPU資源，避免在循環(huán)中浪費等待時間。

Java并發(fā)線程如何阻塞和喚醒？

Java并發(fā)線程的阻塞和喚醒可以分為以下幾類：

它是基于JVM的對象頭實現(xiàn)的。當多線程競爭相同的關(guān)鍵資源時，它們會根據(jù)不同的鎖機制（自旋鎖、輕/重鎖）阻塞和喚醒。

我跳過這里一會兒。一般的實現(xiàn)原理是基于對象的同步隊列與AQS非常相似。

關(guān)注AQS（抽象隊列同步器），因為這是JDK和契約實現(xiàn)的基礎(chǔ)（如鎖、阻塞隊列、倒計時鎖等）。

AQS基本上是通過可變狀態(tài)和等待隊列實現(xiàn)的。CAS先修改狀態(tài)，失敗后放入等待隊列，通過locksupport掛起線程。

當鎖所有者釋放鎖時，它將通過locksupport喚醒等待隊列中的后續(xù)節(jié)點，并讓它們再次嘗試獲取鎖（CAS修改狀態(tài)）。

掌握AQS的原理對于理解JDK中的許多并發(fā)組件非常有幫助。

什么是線程阻塞？

線程a等待線程B的數(shù)據(jù)，線程B等待線程a的數(shù)據(jù)。如果他們互相等待，就會陷入困境。這也是一種螺紋塊。阻塞狀態(tài)是正在運行的線程遇到的一種特殊情況。例如，延遲、掛起、等待I/O操作完成等。處于阻塞狀態(tài)的線程放棄CPU并暫時停止執(zhí)行。線程進入阻塞狀態(tài)后，等待阻塞原因消除，線程進入就緒狀態(tài)，重新進入就緒隊列。