preface

In the previous article, I analyzed the lock source code for fair locks and concluded that:

  1. Redis Hash data structure: holds the current lock, the Redis Key is the lock, the Hash field is the locked thread, and the Hash value is the reentrant times.
  2. Redis List data structure: acts as a waiting queue for threads, and new waiting threads are placed on the right side of the queue using the rpush command.
  3. Data structure: The order in which the waiting threads are sorted. The score is used as a timeout stamp for the waiting threads.

Now let’s look at what happens to the thread after it fails to lock and is put on the wait queue.

Waiting in line for the lock

Source: entrance org. Redisson. RedissonLock# lock (long, Java. Util. Concurrent. TimeUnit, Boolean).

After the thread enters the queue, in the Java code, a while (true) loop calls tryAcquire all the way through, trying to acquire the lock.

And finally we’re in the RedissonFairlock # TryLockinnerAsync method.

For convenience, re-post the Lua script, along with the meaning of the script’s parameters.

  1. Keys [1] : name of lock,anyLock;
  2. Keys [2] : Locked wait queue,redisson_lock_queue:{anyLock};
  3. Keys [3] : Set of thread locking time in wait queueredisson_lock_timeout:{anyLock}Is stored in the collection according to the timestamp of the lock;
  4. ARGV[1] : lock timeout 30000
  5. ARGV[2] : UUID: threaId combinationa3da2c83-b084-425c-a70f-5d9a08b37f31:1
  6. ARGV[3] : ThreadWaitTime defaults to 300,000
  7. ARGV[4] : CurrentTime Current timestamp

Source code analysis

The first part, the while loop:

  1. Slave queueredisson_lock_queue:{anyLock}Gets the first waiting thread in the
  2. Timeout collection from waiting threadsredisson_lock_timeout:{anyLock}Gets the score of the first waiting thread in the
  3. If it does not timeout, it will end. If it does timeout, it will be removed.

The second part, the current lock exists, so skip it.

The current lock is not the thread holding the lock, so skip it.

Part IV,

Directly returns how long the current lock has expired.

The current version of Redisson is 3.15.6, different versions are slightly different.

A rearrangement of the queue

There is no reordering, because the authorities thought it was a bug and fixed it again.

See: Justin Corpron 2019/5/10, 04:13 Fix Timeout Drift in RedissonFairlock

The biggest change is the addition of a fourth section.

The diagram only represents the differences between the two versions, and is not meant to be modified for this version.

conclusion

When the thread fails to acquire the lock and enters the wait queue, TTL! = null, and the lock is constantly being tried in Java code.

When the lock does not exist and the current thread is waiting on the queue head, the lock is acquired directly. This queuing process is the withdrawal of the fair lock.

Related to recommend

  • Redisson distributed lock source code 05: fair lock lock
  • Redisson distributed lock source code 04: Reentrant lock release
  • Redisson distributed lock source code 03: Reentrant lock mutex