引言

前文中了解到AQS借助LockSupport.park和LockSupport.unpark完成線程的阻塞和喚醒，那么LockSupport內(nèi)部又是怎么實(shí)現(xiàn)的？這是一個(gè)什么類？

LockSupport是用于使用鎖阻塞線程的基礎(chǔ)實(shí)現(xiàn)，是其他同步類的基礎(chǔ)，這個(gè)類為每個(gè)使用它的線程關(guān)聯(lián)一個(gè)許可證(有點(diǎn)類似于Semaphore)，如果許可證可用，線程調(diào)用park方法時(shí)會(huì)立即返回，線程正常執(zhí)行，否則當(dāng)前線程阻塞，直到有其他線程調(diào)用unpark使得許可證可用，此時(shí)線程被喚醒，再次嘗試獲取許可證，其內(nèi)部定義的park和unpark方法提供了阻塞和解決阻塞的基本實(shí)現(xiàn)。

LockSupport常見函數(shù)

如下表所示：

LockSupport.park

ReentrantLock中調(diào)用LockSupport.park代碼如下所示：

 // AbstractQueuedSynchronizer.java
 private final boolean parkAndCheckInterrupt() {
     LockSupport.park(this);
     return Thread.interrupted();
 }

在LockSupport中，void park(Object blocker)實(shí)現(xiàn)代碼如下：

 // LockSupport.java
 public static void park(Object blocker) {
     Thread t = Thread.currentThread();
     setBlocker(t, blocker);
     UNSAFE.park(false, 0L);
     setBlocker(t, null);
 }

可以看到在park流程中主要包含以下過程：

獲取當(dāng)前線程

將傳入的對(duì)象設(shè)置為該線程的parkBlocker

setBlocker函數(shù)實(shí)現(xiàn)如下所示：

 private static void setBlocker(Thread t, Object arg) {
     // Even though volatile, hotspot doesn't need a write barrier here.
     UNSAFE.putObject(t, parkBlockerOffset, arg);
 }

可以看到這里新出現(xiàn)了UNSAFE和parkBlockerOffset兩個(gè)標(biāo)識(shí)，這兩個(gè)是用來干嘛的？我們一起看看其聲明的代碼：

 private static final sun.misc.Unsafe UNSAFE;
 private static final long parkBlockerOffset;

 static {
     try {
         UNSAFE = sun.misc.Unsafe.getUnsafe();
         Class<?> tk = Thread.class;
         parkBlockerOffset = UNSAFE.objectFieldOffset
             (tk.getDeclaredField("parkBlocker"));
         .....
     } catch (Exception ex) { throw new Error(ex); }
 }

可以看到UNSAFE對(duì)象是通過Unsafe.getUnsafe()獲取的，那么Unsafe這個(gè)類到底是干嘛的？

大家都知道Java對(duì)象在內(nèi)存中創(chuàng)建，大多數(shù)情況下我們都是通過類的對(duì)象去修改和訪問內(nèi)存中的數(shù)據(jù)的，那么如果需要直接從內(nèi)存修改某一對(duì)象的取值，應(yīng)該怎么做呢？就是使用Unsafe類，該類只允許在JDK信任的類中調(diào)用(當(dāng)前也可以用反射實(shí)例化該類對(duì)象)。

在Unsafe類中定義了兩個(gè)重要函數(shù)park和unpark，其中park用于實(shí)現(xiàn)線程阻塞，unpark用于實(shí)現(xiàn)線程喚醒(Unsafe本質(zhì)上是操作線程的Parker對(duì)象來完成線程阻塞和喚醒的，具體見參考鏈接，了解即可)，上文中的parkBlockerOffset正是定義了Thread類的parkBlocker屬性成員的內(nèi)存偏移量，使用該值再結(jié)合Unsafe對(duì)象就可以實(shí)現(xiàn)直接操作內(nèi)存中的parkBlocker值的目的，Thread類中的parkBlocker聲明如下：

 // Thread.java
 volatile Object parkBlocker;

可以得到這一環(huán)節(jié)主要是將AQS作為blocker設(shè)置到當(dāng)前線程的parkBlocker成員屬性上。

CAS底層也是通過Unsafe執(zhí)行的

執(zhí)行UNSAFE.park

結(jié)合上文可知，這步完成后，當(dāng)前線程阻塞

設(shè)置線程的parkBlocker為null

第三步中線程處于阻塞狀態(tài)，當(dāng)然就不能執(zhí)行設(shè)置parkBlocker為null的操作了，那么什么時(shí)候執(zhí)行呢？當(dāng)線程從阻塞狀態(tài)喚醒時(shí)，執(zhí)行該步驟，使得線程的parkBlocker對(duì)象恢復(fù)初始狀態(tài)。

LockSupport.unpark

LockSupport.unpark代碼如下所示：

 // LockSupport.java
 public static void unpark(Thread thread) {
     if (thread != null)
         UNSAFE.unpark(thread);
 }

可以看出當(dāng)傳入的線程不為空時(shí)，執(zhí)行Unsafe的park函數(shù)喚醒當(dāng)前線程，取消阻塞，此時(shí)繼續(xù)執(zhí)行park函數(shù)中的setBlocker(null)，將parkBlocker成員設(shè)置為null。

參考鏈接  http://chabaoo.cn/article/272073.htm

以上就是java LockSupport實(shí)現(xiàn)原理示例解析的詳細(xì)內(nèi)容，更多關(guān)于java LockSupport原理的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論