[[410513]]

前言

在了解了加鎖和鎖重入之后，最需要了解的還是在分布式場景下或者多線程并發加鎖是如何處理的?

1并發加鎖

先來看結果，在多線程對 /locks/lock_01 加鎖時，是在后面又創建了新的臨時節點。

這塊在加鎖方法 CreateBuilderImpl#pathInForeground 中已經介紹過

這里判斷 /locks/lock_01 路徑已經存在，會直接創建新的臨時順序節點。

真正判斷鎖是否獲取成功，其實是在 LockInternals#attemptLock 方法中的 internalLockLoop 方法中。

加鎖結果及監聽

internalLockLoop 方法的主要作用是判斷加鎖結果，以及獲取鎖失敗時，對其他節點的監聽。

1. 獲取父節點 /locks/lock_01 下的所有子節點，按照從小到大排序，判斷自己是不是獲取到鎖，沒有獲取到就監聽自己前一個節點;
2. 支持設置超時時間，超時直接返回失敗;
3. 不支持設置超時時間或者還沒有超時，則直接 wait 等待。

是否獲取鎖的代碼在 StandardLockInternalsDriver#getsTheLock

這塊就是判斷是否為最小節點，因為在 getSortedChildren 中已經對所有節點排序，所以方法中的 List children 是有序的。

maxLeases 是在 InterProcessMutex 初始化的時候，指定的值為 1。

最終這里的結果是，判斷自己是不是最小，不是最小，就將 pathToWatch 設置為前一個節點。

只監聽自己的前一個節點，可以避免羊群效應!

為什么要進行等待呢?

因為是為了防止無效自旋，因為這里有監聽機制，會監聽上一個節點是否釋放。

這塊是 ZooKeeper 的 Watcher 監聽機制，在節點釋放的時候，會進行回調，然后使用 Java 的 notifyAll 方法通知所有的 wait 線程。然后這里的 while trye 會繼續執行，重新檢查是否獲得鎖等。

2總結

本文主要介紹了基于 ZooKeeper 的分布式鎖框架 Curator 在并發場景下的鎖競爭問題。

重點需要了解的是：

1. 為了避免羊群效應，臨時順序節點，加鎖失敗后監聽的是前一個節點;
2. 為了避免無效自旋，這里使用了 Java 的 wait/notifyAll 機制;
3. 可以看出，默認加鎖就是公平鎖。

本文轉載自微信公眾號「程序員小航」，可以通過以下二維碼關注。轉載本文請聯系程序員小航公眾號。