How Zookeeper’s Curator Implements Distributed Locks: A Deep Dive

Continuing the analysis after the Redis‑based Redisson lock article, this piece examines how Curator implements Zookeeper distributed locks and its related features.

Curator provides a high‑level API for Zookeeper operations, including distributed locking. The Zookeeper lock relies on temporary sequential nodes: when a client attempts to lock, it creates a child node (e.g., lock-000001 ) under a lock path. All child nodes are sorted; if the client’s node is first, the lock is acquired. Otherwise, the client watches the immediate predecessor node. When that predecessor releases the lock (its node is deleted), the watcher notifies the waiting client, which then retries and acquires the lock.

Using a watcher on the previous node prevents the herd effect—only the next client is awakened, reducing server load.

Temporary nodes differ from persistent nodes because they are automatically removed when the client’s Zookeeper session expires, avoiding deadlocks caused by abandoned locks. Persistent nodes remain until explicitly deleted.

Key node types:

Temporary node: deleted on session loss.

Persistent node: remains until explicitly removed.

Sequential node: receives an auto‑incremented suffix; can be temporary or persistent.

Lock acquisition flow:

acquire() calls internalLock(-1, null) , blocking indefinitely until the lock is obtained.

internalLock retrieves thread data, creates a temporary sequential node via driver.createsTheLock , and obtains the node name.

The method internalLockLoop sorts child nodes, checks if the created node is first using driver.getsTheLock , and returns a PredicateResults indicating success or the predecessor node to watch.

If the lock is not acquired, a watcher is set on the predecessor node, and the thread waits ( wait() or wait(timeout) for a timeout).

Re‑entrant locking is achieved by storing a LockData object per thread, which records the lock count and node. Subsequent lock attempts by the same thread increment the count without contacting the server.

Unlike Redisson, which stores re‑entrancy counters on the Redis server, Curator keeps them locally in the client.

When releasing a lock, release() retrieves the thread’s LockData . If the lock count drops to zero, the associated Zookeeper node is deleted; otherwise, the count is simply decremented.

The use of temporary sequential nodes inherently provides a fair lock, as nodes are granted in creation order.

Read‑write locks are implemented by encoding the lock type in the node data. A write lock succeeds only if its node is first; a read lock succeeds if no preceding node holds a write lock, allowing multiple concurrent readers.

Batch locking (multi‑lock) is supported via InterProcessMultiLock , which iterates over a collection of locks and acquires each one; the batch succeeds only when all individual locks are acquired, mirroring Redisson’s RedissonMultiLock approach.

Choosing between Zookeeper and Redis locks involves trade‑offs: Redis offers higher performance (AP), while Zookeeper guarantees stronger consistency (CP) and automatic cleanup via temporary nodes, making it suitable for scenarios requiring strict reliability.

Overall, the article provides a comprehensive walkthrough of Curator’s Zookeeper lock implementation, including code snippets, diagrams, and practical considerations.

<code>boolean acquire(long time, TimeUnit unit) throws Exception</code>