面試侃集合 | SynchronousQueue非公平模式篇

碼農參上發表於2021-06-08
面試模式

面試官：好了，你也休息了十分鐘了，我們們接著往下聊聊SynchronousQueue的非公平模式吧。

Hydra：好的，有了前面公平模式的基礎，非公平模式理解起來就非常簡單了。公平模式下，SynchronousQueue底層使用的是TransferQueue，是一個先進先出的佇列，而非公平模式與它不同，底層採用了後進先出的TransferStack棧來實現。

下面我們還是先寫一個例子來看看效果，首先建立3個執行緒使用put方法向SynchronousQueue中插入資料，結束後再使用3個執行緒呼叫take方法：

SynchronousQueue<Integer> queue=new SynchronousQueue<>(false);

@AllArgsConstructor
class PutThread implements Runnable{
    int i;
    @SneakyThrows
    @Override
    public void run() {
        queue.put(i);
        System.out.println("putThread "+i+" end");
    }
}
class TakeThread implements Runnable{
    @SneakyThrows
    @Override
    public void run() {
        System.out.println("takeThread take: "+queue.take());
    }
}

for (int i = 1; i <=3; i++) {
    new Thread(new PutThread(i)).start();
    Thread.sleep(1000);
}
for (int i = 1; i <=3 ; i++) {
    new Thread(new TakeThread()).start();
    Thread.sleep(1000);
}

執行上面的程式碼，檢視結果：

takeThread take: 3
putThread 3 end
takeThread take: 2
putThread 2 end
takeThread take: 1
putThread 1 end

可以看到，生產者執行緒在執行完put後會進行阻塞，直到有消費者執行緒呼叫take方法取走了資料，才會喚醒被阻塞的執行緒。並且，資料的出隊與入隊順序是相反的，即非公平模式下采用的是後進先出的順序。

面試官：就是把結構從佇列換成了棧，真就這麼簡單？

Hydra：並不是，包括底層節點以及出入棧的邏輯都做了相應的改變。我們先看節點，在之前的公平模式中佇列的節點是QNode，非公平模式下棧中節點是SNode，定義如下：

volatile SNode next; // 指向下一個節點的指標
volatile SNode match; // 存放和它進行匹配的節點
volatile Thread waiter;  // 儲存阻塞的執行緒
Object item;                
int mode;
SNode(Object item) {
    this.item = item;
}

和QNode類似，如果是生產者構建的節點，那麼item非空，如果是消費者產生的節點，那麼item為null。此外還有一個mode屬性用來表示節點的狀態，它使用TransferStack中定義的3個常量來表示不同狀態：

static final int REQUEST    = 0; //消費者
static final int DATA       = 1; //生產者
static final int FULFILLING = 2; //匹配中狀態

TransferStack中沒有攜帶引數的建構函式，使用一個head節點來標記棧頂節點：

volatile SNode head;

面試官：基本結構就講到這吧，還是老規矩，先從入隊操作開始分析吧。

Hydra：當棧為空、或棧頂元素的型別與自己相同時，會先建立一個SNode節點，並將它的next節點指向當前棧頂的head，然後將head指標指向自己。這個過程中通過使用CAS保證執行緒安全，如果失敗則退出，在迴圈中採取自旋的方式不斷進行嘗試，直到節點入棧成功。用一張圖來表示兩個執行緒同時入棧的場景：

當節點完成入棧後，呼叫awaitFulfill方法，等待匹配的操作的到來。在這一過程中，會使節點對應的執行緒進行自旋或掛起操作，直到匹配操作的節點將自己喚醒，或被其他執行緒中斷、等待超時。

當入棧後的節點是棧頂節點，或者節點的型別為FULFILLING匹配狀態時，那麼可能會馬上完成匹配，因此先進行自旋，當超過自旋次數上限後再掛起。而如果節點在自旋過程中，有新的節點壓入棧頂，會將非棧頂節點剩餘的自旋次數直接清零，掛起執行緒避免浪費資源。

面試官：你上面也說了，掛起的執行緒有可能會超時或者被中斷，這時候應該怎麼處理？

Hydra：當這兩種情況出現時，SNode會將match屬性設為自身，退出awaitFulfill方法，然後呼叫clean方法將對應的節點清理出棧。具體情形可分為兩種情況。先說簡單的情況，如果清理的是棧頂節點，那麼直接將head節點指向它的next節點，即將當前棧頂結點彈出即可。

面試官：那麼如果要刪除的節點不是棧頂的節點呢？

Hydra：如果清理的不是棧頂節點，會稍微有一些麻煩。因為棧的底層是一個單向的連結串列結構，所以需要從棧頂head節點開始遍歷，遍歷到被刪除節點的後繼節點為止。所以在清除工作開始前，先使用了一個past節點標記需要刪除節點的下一個節點，作為結束遍歷的標記。

然後建立一個標記節點p，初始時指向head結點，開始迴圈，如果p的next節點不是需要被刪除的節點，那麼就將p向後移一個位置，直到找到這個需要被刪除的中斷或超時的節點，然後將p的next指向這個刪除節點的next節點，在邏輯上完成連結串列中節點的刪除。

面試官：單一型別節點的入棧應該說完了吧，接下來說說不同型別節點間是如何實現的匹配操作吧？

Hydra：好的，那我們先回顧一點上面的知識，前面說過每個節點有一個mode屬性代表它的模式，REQUEST表示它是消費者，DATA表示是生產者，FULFILLING表明正處於匹配中的狀態。

在一個新的執行緒呼叫方法時，先判斷它的型別mode是什麼，如果和當前棧頂head節點型別不同，且head節點的狀態不為匹配中時，將它的狀態設定為FULFILLING|mode，壓入棧中。然後將嘗試匹配新的head節點和它的next節點，如果匹配成功，會將next節點的match屬性設定為head節點，喚醒掛起的next節點中的執行緒。

在完成匹配後，當前頭結點對應的執行緒會協助推進head節點，將head指向next節點的下一個節點，即完成了棧頂兩節點的出棧。最終消費者執行緒會返回匹配的生產者節點中的item資料值，而生產者執行緒也會結束執行退出。

我們以棧中當前節點為DATA型別，新節點為REQUEST型別畫一張圖，來直觀的感受一下上面的流程：

面試官：總算是講完了，能對SynchronousQueue做一個簡單的總結嗎？

Hydra：SynchronousQueue基於底層結構，實現了執行緒配對通訊這一機制。在它的公平模式下使用的是先進先出（FIFO）的佇列，非公平模式下使用的是後進先出（LIFO）的棧，並且SynchronousQueue沒有使用synchronized或ReentrantLock，而是使用了大量的CAS操作來保證併發操作。可能我們在平常的工作中使用場景不是很多，但是線上程池的設計中使用了SynchronousQueue，還是有很重要的應用場景的。

面試官：講的還行，不過剛才這些和公平模式聽起來感覺區別不大啊，沒有什麼技術含量。這樣吧，你明天過來我們加試一場，我再給你打分。

Hydra：（溜了溜了，還是找家別的靠譜公司吧……）

最後

如果覺得對您有所幫助，小夥伴們可以點贊、轉發一下~非常感謝

微信搜尋：碼農參上，來加個好友，點贊之交也好啊~

公眾號後臺回覆“面試”、“導圖”、“架構”、“實戰”，獲得免費資料哦~

相關文章