Outline
Read and write lock RedissonReadWriteLock Overview
2. Read lock RedissonReadLock's acquisition read lock logic
3. Write lock RedissonWriteLock acquire write lock logic
4. Read lock RedissonReadLock's read-read-not mutually exclusive logic
Read and write mutex logic of RedissonWriteLock
6. Write-write mutex logic of RedissonWriteLock
7. Reentrant logic of write lock RedissonWriteLock
8. Release the read lock logic of RedissonReadLock
9. Write lock RedissonWriteLock release write lock logic
Read and write lock RedissonReadWriteLock Overview
(1) Introduction to RedissonReadWriteLock
(2) Use of RedissonReadWriteLock
(3) Initialization of RedissonReadWriteLock
(1) Introduction to RedissonReadWriteLock
RedissonReadWriteLock provides two methods to acquire read lock and write lock respectively.
The readLock() method of RedissonReadWriteLock can obtain the read lock RedissonReadLock.
RedissonReadWriteLock's writeLock() method can obtain the write lock RedissonWriteLock.
Since RedissonReadLock and RedissonWriteLock are both subclasses of RedissonLock, you only need to pay attention to the following contents of RedissonReadLock and RedissonWriteLock.
The first is to obtain the lua script logic of read lock (write lock)
The second is to release the lua script logic of the read lock (write lock)
The third is the logic of WathDog for reading lock (write lock) checking the reading lock (write lock) and processing the lock expiration time.
(2) Use of RedissonReadWriteLock
//Read and write lock
RedissonClient redisson = (config);
RReadWriteLock rwlock = ("myLock");
().lock();//Acquiring the read lock
().unlock();//Release the read lock
().lock();//Acquire the write lock
().unlock();//Release the write lock
---------------------------------------------------------------
//If the lock is not released actively, the lock will be automatically released in 10 seconds
().lock(10, );
().lock(10, );
//Waiting for locking is up to 100 seconds; if the lock is not released actively after locking is successfully completed, the lock will be automatically released after 10 seconds.
boolean res = ().tryLock(100, 10, );
boolean res = ().tryLock(100, 10, );(3) Initialization of RedissonReadWriteLock
RedissonReadWriteLock implements the RReadWriteLock interface, RedissonReadLock implements the RLock interface, and RedissonWriteLock implements the RLock interface.
public class Redisson implements RedissonClient {
//Redis's connection manager encapsulates a Config instance
protected final ConnectionManager connectionManager;
//Redis's command executor encapsulates a ConnectionManager instance
protected final CommandAsyncExecutor commandExecutor;
...
protected Redisson(Config config) {
= config;
Config configCopy = new Config(config);
//Initialize Redis's connection manager
connectionManager = (configCopy);
...
//Initialize Redis command executor
commandExecutor = new CommandSyncService(connectionManager, objectBuilder);
...
}
@Override
public RReadWriteLock getReadWriteLock(String name) {
return new RedissonReadWriteLock(commandExecutor, name);
}
...
}
public class RedissonReadWriteLock extends RedissonExpirable implements RReadWriteLock {
public RedissonReadWriteLock(CommandAsyncExecutor commandExecutor, String name) {
super(commandExecutor, name);
}
@Override
public RLock readLock() {
return new RedissonReadLock(commandExecutor, getRawName());
}
@Override
public RLock writeLock() {
return new RedissonWriteLock(commandExecutor, getRawName());
}
}
public class RedissonReadLock extends RedissonLock implements RLock {
public RedissonReadLock(CommandAsyncExecutor commandExecutor, String name) {
super(commandExecutor, name);
}
...
}
public class RedissonWriteLock extends RedissonLock implements RLock {
protected RedissonWriteLock(CommandAsyncExecutor commandExecutor, String name) {
super(commandExecutor, name);
}
...
}
2. Read lock RedissonReadLock's acquisition read lock logic
(1) Lua script logic with read lock
(2) WathDog handles the lua script logic for reading lock expiration time
(1) Lua script logic with read lock
Suppose the thread of client A (UUID1:ThreadID1) comes in as the first thread to add the read lock, and the execution process is as follows:
public class RedissonLock extends RedissonBaseLock {
...
//Lock without parameters
public void lock() {
...
lock(-1, null, false);
...
}
//Lock with parameters
public void lock(long leaseTime, TimeUnit unit) {
...
lock(leaseTime, unit, false);
...
}
private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
long threadId = ().getId();
Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
//Locking successfully
if (ttl == null) {
return;
}
//Locking failed
...
}
private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
return get(tryAcquireAsync(waitTime, leaseTime, unit, threadId));
}
private <T> RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
RFuture<Long> ttlRemainingFuture;
if (leaseTime != -1) {
ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
} else {
//Unfair lock, next call is the () method
//Fair lock, next call is the () method
//Read lock in read and write lock, and then call the() method
ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime, , threadId, RedisCommands.EVAL_LONG);
}
//Add callback listening to ttlRemainingFuture of type RFuture<Long>
CompletionStage<Long> f = (ttlRemaining -> {
//The lock lua script in tryLockInnerAsync() has been executed asynchronously, and the following method logic will be called back:
//Locking successfully
if (ttlRemaining == null) {
if (leaseTime != -1) {
//If the incoming leaseTime is not -1, that is, the expiration time of the specified lock, then no timed scheduled task will be created
internalLockLeaseTime = (leaseTime);
} else {
//Create a scheduled schedule task
scheduleExpirationRenewal(threadId);
}
}
return ttlRemaining;
});
return new CompleteFutureWrapper<>(f);
}
...
}
public class RedissonReadLock extends RedissonLock implements RLock {
...
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), command,
//Execute the command "hget myLock mode" to try to get a Hash value mode
"local mode = ('hget', KEYS[1], 'mode'); " +
// If mode is false, the logic of adding a lock is executed
"if (mode == false) then " +
//hset myLock mode read
"('hset', KEYS[1], 'mode', 'read'); " +
//hset myLock UUID1:ThreadID1 1
"('hset', KEYS[1], ARGV[2], 1); " +
//set {myLock}:UUID1:ThreadID1:rwlock_timeout:1 1
"('set', KEYS[2] .. ':1', 1); " +
//pexpire {myLock}:UUID1:ThreadID1:rwlock_timeout:1 30000
"('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
//pexpire myLock 30000
"('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
//If a thread has already added a read lock, or a thread has added a write lock and it has added a write lock by itself.
//So if a thread has a write lock, it can reenter its own write lock and its own read lock.
"if (mode == 'read') or (mode == 'write' and ('hexists', KEYS[1], ARGV[3]) == 1) then " +
//hincrby myLock UUID2:ThreadID2 1
//ind indicates the number of reentries. The thread can reenter its own read lock and write lock. The read lock added after the thread can reenter the thread's own read lock or write lock
"local ind = ('hincrby', KEYS[1], ARGV[2], 1); " +
//key = {myLock}:UUID2:ThreadID2:rwlock_timeout:1
"local key = KEYS[2] .. ':' .. ind;" +
//set {myLock}:UUID2:ThreadID2:rwlock_timeout:1 1
"('set', key, 1); " +
//pexpire myLock 30000
"('pexpire', key, ARGV[1]); " +
"local remainsTime = ('pttl', KEYS[1]); " +
//pexpire {myLock}:UUID2:ThreadID2:rwlock_timeout:1 30000
"('pexpire', KEYS[1], (remainTime, ARGV[1])); " +
"return nil; " +
"end;" +
//Execute the command "pttl myLock" to return the remaining expiration time of myLock
"return ('pttl', KEYS[1]);",
//KEYS[1] = myLock
//KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout or KEYS[2] = {myLock}:UUID2:ThreadID2:rwlock_timeout
Arrays.<Object>asList(getRawName(), getReadWriteTimeoutNamePrefix(threadId)),
(leaseTime),//ARGV[1] = 30000
getLockName(threadId),//ARGV[2] = UUID1:ThreadID1 or ARGV[2] = UUID2:ThreadID2
getWriteLockName(threadId)//ARGV[3] = UUID1:ThreadID1:write or ARGV[3] = UUID2:ThreadID2:write
);
}
...
}1. Parameter description
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1
ARGV[3] = UUID1:ThreadID1:write2. Execute the lua script to get read lock logic
First, execute the command "hget myLock mode" and try to get a Hash value mode, that is, get a value value with field mode from the Hash value with key myLock. But at the beginning, there was no locking at the beginning, so the mode must be false. So the following logic of reading locks is executed: set two Hash values + set a string.
hset myLock mode read
//Used to record the number of times the current client thread reenters the lock
hset myLock UUID1:ThreadID1 1
//Used to record the expiration time of the first reentry lock of the current client thread
set {myLock}:UUID1:ThreadID1:rwlock_timeout:1 1
pexpire {myLock}:UUID1:ThreadID1:rwlock_timeout:1 30000
pexpire myLock 30000After executing the read-lock logic, Redis has data in the following structure. In fact, the core of adding read locks is to construct an incremental sequence that records read locks of different threads and different reentry locks of the same thread.
field is a value similar to UUID1:ThreadID1, which is used to record the number of times the client thread reentries locks. The key is a String similar to {myLock}:UUID1:ThreadID1:rwlock_timeout:1, which is used to record the expiration time of the nth reentry lock of the current client thread.
Suppose that the key is myLock is called the parent read lock, and the key is UUID1:ThreadID1 is called the child read lock. Then the expiration time of each child read lock is recorded because the expiration time of the parent read lock needs to be updated according to the expiration time of multiple child read locks.
//1. Thread 1 first read lock added
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
//2. Thread 1 adds the second read lock
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 2
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
//3. Thread 1 adds the third read lock
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 3
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:3 ==> 1
//4. Thread 2 first read lock added
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 3,
"UUID2:ThreadID2": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:3 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1
//5. Thread 2 second read lock
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 3,
"UUID2:ThreadID2": 2
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:3 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:2 ==> 1(2) WathDog handles the lua script logic for reading lock expiration time
Assuming that the thread of client A (UUID1:ThreadID1) has successfully acquired a read lock, a WatchDog timed scheduling task will be created and the read lock will be checked after 10 seconds. The execution process is as follows:
public abstract class RedissonBaseLock extends RedissonExpirable implements RLock {
...
protected void scheduleExpirationRenewal(long threadId) {
ExpirationEntry entry = new ExpirationEntry();
ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);
if (oldEntry != null) {
(threadId);
} else {
(threadId);
try {
//Create a scheduled schedule task that updates expiration time
renewExpiration();
} finally {
if (().isInterrupted()) {
cancelExpirationRenewal(threadId);
}
}
}
}
//Update expiration time
private void renewExpiration() {
ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (ee == null) {
return;
}
//Used Netty's timing task mechanism: HashedWheelTimer + TimerTask + Timeout
//Create a timed scheduling task that updates the expiration time, and the () method will be called below
//Create a timed scheduling task TimerTask and hand it over to the HashedWheelTimer, and execute it after 10 seconds
Timeout task = ().newTimeout(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (ent == null) {
return;
}
Long threadId = ();
if (threadId == null) {
return;
}
//Execute the lua script asynchronously to update the expiration time of the lock
//For read and write locks, the () method will be executed next
RFuture<Boolean> future = renewExpirationAsync(threadId);
((res, e) -> {
if (e != null) {
("Can't update lock " + getRawName() + " expiration", e);
EXPIRATION_RENEWAL_MAP.remove(getEntryName());
return;
}
//res is the return value of the lua script in renewExpirationAsync()
if (res) {
//Reschedule yourself
renewExpiration();
} else {
//Execute cleaning work
cancelExpirationRenewal(null);
}
});
}
}, internalLockLeaseTime / 3, );
(task);
}
protected void cancelExpirationRenewal(Long threadId) {
ExpirationEntry task = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (task == null) {
return;
}
if (threadId != null) {
(threadId);
}
if (threadId == null || ()) {
Timeout timeout = ();
if (timeout != null) {
();
}
EXPIRATION_RENEWAL_MAP.remove(getEntryName());
}
}
...
}
public class RedissonReadLock extends RedissonLock implements RLock {
...
@Override
protected RFuture<Boolean> renewExpirationAsync(long threadId) {
String timeoutPrefix = getReadWriteTimeoutNamePrefix(threadId);
String keyPrefix = getKeyPrefix(threadId, timeoutPrefix);
return evalWriteAsync(getRawName(), RedisCommands.EVAL_BOOLEAN,
//Execute the command "hget myLock UUID1:ThreadID1" to obtain whether the current thread still holds this read lock
"local counter = ('hget', KEYS[1], ARGV[2]); " +
"if (counter ~= false) then " +
//The specified thread is still holding the lock, then execute "pexpire myLock 30000" to refresh the expiration time of the lock
"('pexpire', KEYS[1], ARGV[1]); " +
"if (('hlen', KEYS[1]) > 1) then " +
//Get all keys whose key is the Hash value of myLock
"local keys = ('hkeys', KEYS[1]); " +
//Transactions on all reentrant and non-reentrant read locks that have been acquired by the thread
"for n, key in ipairs(keys) do " +
"counter = tonumber(('hget', KEYS[1], key)); " +
//Exclude the Hash value with key mode
"if type(counter) == 'number' then " +
//Decrement the key of the splicing reentry lock, refresh the expiration time of all reentry locks in the same thread
"for i=counter, 1, -1 do " +
"('pexpire', KEYS[2] .. ':' .. key .. ':rwlock_timeout:' .. i, ARGV[1]); " +
"end; " +
"end; " +
"end; " +
"end; " +
"return 1; " +
"end; " +
"return 0;",
//KEYS[1] = myLock
//KEYS[2] = {myLock}
Arrays.<Object>asList(getRawName(), keyPrefix),
internalLockLeaseTime,//ARGV[1] = 30000ms
getLockName(threadId)//ARGV[2] = UUID1:ThreadID1
);
}
...
}1. Parameter description
KEYS[1] = myLock
KEYS[2] = {myLock}
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID12. Processing logic for executing lua scripts
Run the command "hget myLock UUID1:ThreadID1" to try to get a Hash value, that is, to get whether the specified thread still holds the read lock. If the specified thread is still holding this lock, then the return is 1, and the "pexpire myLock 30000" refreshes the expiration time of the lock.
Then execute the command "hlen myLock" to determine whether the number of Hash elements whose key is the lock name is greater than 1. If the specified thread is still holding the lock, then the Hash value of the key is myLock, there will be at least two kv pairs. One of the keys is mode and the other key is UUID1:ThreadID1. So the judgment here is valid, so the hash value whose key is the lock name is traversal.
When traversing the hash value whose key is the lock name, you need to exclude the Hash value whose key is mode. Then, according to the Hash value of the key UUID + thread ID, the expiration time is refreshed by decreasing splicing and traversing the read lock of each different thread or the different reentry lock of the same thread.
3. Summary
When WatchDog handles read locks, if the specified thread still holds the read lock, then it will: the expiration time of refreshing the read lock key is 30 seconds, and iterates according to the number of reentry read locks, and the expiration time of the corresponding key of the reentry read lock is also refreshed to 30 seconds.
//KEYS[1] = myLock
//KEYS[2] = {myLock}
"if (('hlen', KEYS[1]) > 1) then " +
"local keys = ('hkeys', KEYS[1]); " +
//Transaction hash value whose key is lock name
"for n, key in ipairs(keys) do " +
"counter = tonumber(('hget', KEYS[1], key)); " +
//Exclude the Hash value with key mode
"if type(counter) == 'number' then " +
"for i=counter, 1, -1 do " +
//Decreasing splicing, refresh the expiration time of read locks of different threads or different reentry locks of the same thread.
"('pexpire', KEYS[2] .. ':' .. key .. ':rwlock_timeout:' .. i, ARGV[1]); " +
"end; " +
"end; " +
"end; " +
"end; " +
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 3,
"UUID2:ThreadID2": 2
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:3 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:2 ==> 1
3. Write lock RedissonWriteLock acquire write lock logic
(1) Execution process of obtaining write lock
(2) Obtain the Lua script logic for writing lock
(1) Execution process of obtaining write lock
Suppose the thread of client A (UUID1:ThreadID1) comes in as the first thread to add a write lock, and the execution process is as follows:
public class RedissonLock extends RedissonBaseLock {
...
//Lock without parameters
public void lock() {
...
lock(-1, null, false);
...
}
//Lock with parameters
public void lock(long leaseTime, TimeUnit unit) {
...
lock(leaseTime, unit, false);
...
}
private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
long threadId = ().getId();
Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
//Locking successfully
if (ttl == null) {
return;
}
//Locking failed
...
}
private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
return get(tryAcquireAsync(waitTime, leaseTime, unit, threadId));
}
private <T> RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
RFuture<Long> ttlRemainingFuture;
if (leaseTime != -1) {
ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
} else {
//Unfair lock, next call is the () method
//Fair lock, next call is the () method
//Read lock in read and write lock, and then call the() method
//The write lock in the read and write lock, and then call the() method
ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime, , threadId, RedisCommands.EVAL_LONG);
}
//Add callback listening to ttlRemainingFuture of type RFuture<Long>
CompletionStage<Long> f = (ttlRemaining -> {
//The lock lua script in tryLockInnerAsync() has been executed asynchronously, and the following method logic will be called back:
//Locking successfully
if (ttlRemaining == null) {
if (leaseTime != -1) {
//If the incoming leaseTime is not -1, that is, the expiration time of the specified lock, then no timed scheduled task will be created
internalLockLeaseTime = (leaseTime);
} else {
//Create a scheduled schedule task
scheduleExpirationRenewal(threadId);
}
}
return ttlRemaining;
});
return new CompleteFutureWrapper<>(f);
}
...
}
public class RedissonWriteLock extends RedissonLock implements RLock {
...
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), command,
//Execute the command "hget myLock mode" to try to get a Hash value mode
"local mode = ('hget', KEYS[1], 'mode'); " +
//Not available, it means that there is no read lock or write lock added
"if (mode == false) then " +
"('hset', KEYS[1], 'mode', 'write'); " +
"('hset', KEYS[1], ARGV[2], 1); " +
"('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
//If you have added a lock, it depends on whether it is a write lock + whether the write lock is added by yourself (that is, re-enter the write lock)
"if (mode == 'write') then " +
"if (('hexists', KEYS[1], ARGV[2]) == 1) then " +
//Re-enter the write lock
"('hincrby', KEYS[1], ARGV[2], 1); " +
"local currentExpire = ('pttl', KEYS[1]); " +
"('pexpire', KEYS[1], currentExpire + ARGV[1]); " +
"return nil; " +
"end; " +
"end;" +
//Execute the command "pttl myLock" to return the remaining expiration time of myLock
"return ('pttl', KEYS[1]);",
Arrays.<Object>asList(getRawName()),//KEYS[1] = myLock
(leaseTime),//ARGV[1] = 30000
getLockName(threadId)//ARGV[2] = UUID1:ThreadID1:write
);
}
...
}(2) Obtain the Lua script logic for writing lock
1. Parameter description
KEYS[1] = myLock
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1:write2. Execution analysis
First, execute the command "hget myLock mode" and try to get a Hash value mode, that is, get a value value with field mode from the Hash value with key myLock. But at the beginning, there was no locking at the beginning, so the mode must be false. So the following logic of reading locks is executed: setting two hash values.
hset myLock mode write
hset myLock UUID1:ThreadID1:write 1
pexpire myLock 30000After completing the lock operation, the following data exists in Redis:
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1
}
4. Read lock RedissonReadLock's read-read-not mutually exclusive logic
(1) The reading lock and reading lock are not mutually exclusive to different client threads
(2) Client A first adds the Redis command execution process and results of the read lock
(3) The Redis command execution process and results of the read lock added to the client B after the client B
(1) The reading lock and reading lock are not mutually exclusive to different client threads
Suppose client A (UUID1:ThreadID1) adds a read lock to the myLock lock first, and client B (UUID2:ThreadID2) also needs to add a read lock to the myLock lock, then these two read locks will not be mutually exclusive at this time, and client B can add the lock successfully.
public class RedissonReadLock extends RedissonLock implements RLock {
...
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), command,
//Execute the command "hget myLock mode" to try to get a Hash value mode
"local mode = ('hget', KEYS[1], 'mode'); " +
// If mode is false, the logic of adding a lock is executed
"if (mode == false) then " +
//hset myLock mode read
"('hset', KEYS[1], 'mode', 'read'); " +
//hset myLock UUID1:ThreadID1 1
"('hset', KEYS[1], ARGV[2], 1); " +
//set {myLock}:UUID1:ThreadID1:rwlock_timeout:1 1
"('set', KEYS[2] .. ':1', 1); " +
//pexpire {myLock}:UUID1:ThreadID1:rwlock_timeout:1 30000
"('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
//pexpire myLock 30000
"('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
//If a thread has already added a read lock, or a thread has added a write lock and it has added a write lock by itself.
//So if a thread has a write lock, it can reenter its own write lock and its own read lock.
"if (mode == 'read') or (mode == 'write' and ('hexists', KEYS[1], ARGV[3]) == 1) then " +
//hincrby myLock UUID2:ThreadID2 1
//ind indicates the number of reentries. The thread can reenter its own read lock and write lock. The read lock added after the thread can reenter the thread's own read lock or write lock
"local ind = ('hincrby', KEYS[1], ARGV[2], 1); " +
//key = {myLock}:UUID2:ThreadID2:rwlock_timeout:1
"local key = KEYS[2] .. ':' .. ind;" +
//set {myLock}:UUID2:ThreadID2:rwlock_timeout:1 1
"('set', key, 1); " +
//pexpire myLock 30000
"('pexpire', key, ARGV[1]); " +
"local remainsTime = ('pttl', KEYS[1]); " +
//pexpire {myLock}:UUID2:ThreadID2:rwlock_timeout:1 30000
"('pexpire', KEYS[1], (remainTime, ARGV[1])); " +
"return nil; " +
"end;" +
//Execute the command "pttl myLock" to return the remaining expiration time of myLock
"return ('pttl', KEYS[1]);",
//KEYS[1] = myLock
//KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout or KEYS[2] = {myLock}:UUID2:ThreadID2:rwlock_timeout
Arrays.<Object>asList(getRawName(), getReadWriteTimeoutNamePrefix(threadId)),
(leaseTime),//ARGV[1] = 30000
getLockName(threadId),//ARGV[2] = UUID1:ThreadID1 or ARGV[2] = UUID2:ThreadID2
getWriteLockName(threadId)//ARGV[3] = UUID1:ThreadID1:write or ARGV[3] = UUID2:ThreadID2:write
);
}
...
}(2) Client A first adds the Redis command execution process and results of the read lock
Parameter description:
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1
ARGV[3] = UUID1:ThreadID1:writeThe execution process of Redis command:
hset myLock mode read
hset myLock UUID1:ThreadID1 1
set {myLock}:UUID1:ThreadID1:rwlock_timeout:1 1
pexpire {myLock}:UUID1:ThreadID1:rwlock_timeout:1 30000
pexpire myLock 30000Redis execution results:
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1(3) The Redis command execution process and results of the read lock added to the client B after the client B
Parameter description:
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID2:ThreadID2:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID2:ThreadID2
ARGV[3] = UUID2:ThreadID2:writeThe execution process of Redis command:
hget myLock mode ===> Get mode=read, indicating that a thread has added a read lock at this time
hincrby myLock UUID2:ThreadID2 1
set {myLock}:UUID2:ThreadID2:rwlock_timeout:1 1
pexpire myLock 30000
pexpire {myLock}:UUID2:ThreadID2:rwlock_timeout:1 30000Redis execution results:
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1,
"UUID2:ThreadID2": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1It should be noted that multiple clients add read locks at the same time, and read locks and read locks are not mutually exclusive. The value of the field that is the client UUID + thread ID will be increased by itself in the Hash where the key is the lock name. A read or write lock successfully added by each client will maintain a WatchDog, constantly refreshing the survival time of myLock + refreshing the expiration time of the lock added by the client this time.
In the lua script that adds the read lock, ind represents the number of reentries. Threads can reenter their own read and write locks. In other words, the read lock added after the thread can reenter the read lock or write lock added first by the thread.
Read and write mutex logic of RedissonWriteLock
(1) How to mutually exclusively the locks read first and then write to different client threads
(2) How do different client threads write locks first and then read locks mutually exclusive?
(1) How to mutually exclusively the locks read first and then write to different client threads
First, client A (UUID1:ThreadID1) and client B (UUID2:ThreadID2) first add the read lock. At this time, the following data exists in Redis:
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1,
"UUID2:ThreadID2": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1Next, client C (UUID3:ThreadID3) adds a write lock.
public class RedissonWriteLock extends RedissonLock implements RLock {
...
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), command,
//Execute the command "hget myLock mode" to try to get a Hash value mode
"local mode = ('hget', KEYS[1], 'mode'); " +
//At this time, mode=read is found, which means that a thread has been locked.
"if (mode == false) then " +
"('hset', KEYS[1], 'mode', 'write'); " +
"('hset', KEYS[1], ARGV[2], 1); " +
"('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
//If you have added a lock, it depends on whether it is a write lock + whether the write lock is added by yourself (that is, re-enter the write lock)
"if (mode == 'write') then " +
"if (('hexists', KEYS[1], ARGV[2]) == 1) then " +
//Re-enter the write lock
"('hincrby', KEYS[1], ARGV[2], 1); " +
"local currentExpire = ('pttl', KEYS[1]); " +
"('pexpire', KEYS[1], currentExpire + ARGV[1]); " +
"return nil; " +
"end; " +
"end;" +
//Execute the command "pttl myLock" to return the remaining expiration time of myLock
"return ('pttl', KEYS[1]);",
Arrays.<Object>asList(getRawName()),//KEYS[1] = myLock
(leaseTime),//ARGV[1] = 30000
getLockName(threadId)//ARGV[2] = UUID3:ThreadID3:write
);
}
...
}Parameters when client C (UUID3:ThreadID3) write lock:
KEYS[1] = myLock
ARGV[1] = 30000
ARGV[2] = UUID3:ThreadID3:writeWhen adding a lock on client C (UUID3:ThreadID3): First execute the command "hget myLock mode" and find that mode = read, which means that a thread has locked it. Because the lock that has been added is not a write lock added by the current thread, but a read lock added by other threads. Therefore, the command "pttl myLock" will be executed at this time to return the remaining expiration time of myLock. This will cause the client C to fail to lock, block and retry in the while loop, thereby realizing the mutual exclusion of reading the lock first and then writing the lock.
(2) How do different client threads write locks first and then read locks mutually exclusive?
Suppose client A (UUID1:ThreadID1) first adds a write lock, and the following data exists in Redis:
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1
}Then client B (UUID2:ThreadID2) adds the read lock.
public class RedissonReadLock extends RedissonLock implements RLock {
...
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), command,
//Execute the command "hget myLock mode" to try to get a Hash value mode
"local mode = ('hget', KEYS[1], 'mode'); " +
//I found that mode=write means that a thread has been locked
"if (mode == false) then " +
"('hset', KEYS[1], 'mode', 'read'); " +
"('hset', KEYS[1], ARGV[2], 1); " +
"('set', KEYS[2] .. ':1', 1); " +
"('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
"('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
//If a thread has already added a read lock, or a thread has added a write lock and it has added a write lock by itself.
//So if a thread has a write lock, it can reenter its own write lock and its own read lock.
"if (mode == 'read') or (mode == 'write' and ('hexists', KEYS[1], ARGV[3]) == 1) then " +
//hincrby myLock UUID2:ThreadID2 1
//ind indicates the number of reentries. The thread can reenter its own read lock and write lock. The read lock added after the thread can reenter the thread's own read lock or write lock
"local ind = ('hincrby', KEYS[1], ARGV[2], 1); " +
//key = {myLock}:UUID2:ThreadID2:rwlock_timeout:1
"local key = KEYS[2] .. ':' .. ind;" +
//set {myLock}:UUID2:ThreadID2:rwlock_timeout:1 1
"('set', key, 1); " +
//pexpire myLock 30000
"('pexpire', key, ARGV[1]); " +
"local remainsTime = ('pttl', KEYS[1]); " +
//pexpire {myLock}:UUID2:ThreadID2:rwlock_timeout:1 30000
"('pexpire', KEYS[1], (remainTime, ARGV[1])); " +
"return nil; " +
"end;" +
//Execute the command "pttl myLock" to return the remaining expiration time of myLock
"return ('pttl', KEYS[1]);",
//KEYS[1] = myLock
//KEYS[2] = {myLock}:UUID2:ThreadID2:rwlock_timeout
Arrays.<Object>asList(getRawName(), getReadWriteTimeoutNamePrefix(threadId)),
(leaseTime),//ARGV[1] = 30000
getLockName(threadId),//ARGV[2] = UUID2:ThreadID2
getWriteLockName(threadId)//ARGV[3] = UUID2:ThreadID2:write
);
}
...
}Parameters when client B (UUID2:ThreadID2) adds read lock:
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID2:ThreadID2:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID2:ThreadID2
ARGV[3] = UUID2:ThreadID2:writeWhen adding a lock on client B (UUID2:ThreadID2): First, execute the command "hget myLock mode" and find that mode = write, which means that a thread has locked it. Next, execute the command "hexists myLock UUID2:ThreadID2:write" and find that it does not exist. In other words, if client B has added a write lock before, then B can only make a judgment by adding a read lock. However, the client A who added the write lock before, so the judgment condition here will not pass. Then "pttl myLock" is returned, causing the read lock to fail, which will block and retry in the while loop, thereby realizing the mutual exclusion of writing the lock first and then reading the lock.
(3) Summary
If the client thread A has added a write lock before, then the thread has added a read lock, it can be successful.
If the client thread A first adds a write lock before, then the thread adds a write lock, it can be successful.
If the client thread A has added a read lock before, then the thread has added a read lock, it can be successful.
If the client thread A first adds a read lock, then the thread adds a write lock and cannot be successful.
Therefore, the write lock can be reentered by its own write lock or reentered by its own read lock. However, the read lock can be reentered by any read lock, and cannot be reentered by any write lock.
6. Write-write mutex logic of RedissonWriteLock
(1) The situation where different client threads write locks first
(2) The situation of writing locks on different client threads
(1) The situation where different client threads write locks first
Suppose client A (UUID1:ThreadID1) adds a lock first:
//Passed in parameters
KEYS[1] = myLock
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1:write
//Execution results
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1
}(2) The situation of writing locks on different client threads
Suppose client B (UUID2:ThreadID2) adds a write lock: First, execute the command "hget myLock mode" and finds mode = write, which means that a thread has added a write lock. Then continue to execute the command "hexists myLock UUID2:ThreadID2:write" to determine whether the added write lock is added by the current client B (UUID2:ThreadID2). Since the added write lock is added by client A (UUID1:ThreadID1), the judgment is not passed. So execute "pttl myLock" to return the remaining expiration time of myLock. This will cause the client B to write lock to fail, and the write lock will be blocked and retryed in the while loop, thereby realizing the mutual exclusion of write locks and write locks of different client threads.
public class RedissonWriteLock extends RedissonLock implements RLock {
...
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), command,
//Execute the command "hget myLock mode" to try to get a Hash value mode
"local mode = ('hget', KEYS[1], 'mode'); " +
//Not available, it means that there is no read lock or write lock added
"if (mode == false) then " +
"('hset', KEYS[1], 'mode', 'write'); " +
"('hset', KEYS[1], ARGV[2], 1); " +
"('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
//If the lock has been added, it depends on whether it is a write lock + whether the write lock has been added by yourself (that is, re-enter the write lock)
"if (mode == 'write') then " +
"if (('hexists', KEYS[1], ARGV[2]) == 1) then " +
//Re-enter the write lock
"('hincrby', KEYS[1], ARGV[2], 1); " +
"local currentExpire = ('pttl', KEYS[1]); " +
"('pexpire', KEYS[1], currentExpire + ARGV[1]); " +
"return nil; " +
"end; " +
"end;" +
//Execute the command "pttl myLock" to return the remaining expiration time of myLock
"return ('pttl', KEYS[1]);",
Arrays.<Object>asList(getRawName()),//KEYS[1] = myLock
(leaseTime),//ARGV[1] = 30000
getLockName(threadId)//ARGV[2] = UUID1:ThreadID1:write or ARGV[2] = UUID2:ThreadID2:write
);
}
...
}
7. Reentrant logic of write lock RedissonWriteLock
(1) The same client thread first adds the read lock and then adds the read lock
(2) The same client thread first adds the read lock and then write lock
(3) The same client thread first adds the write lock and then adds the read lock.
(4) The same client thread first adds a write lock and then a write lock
The previous analysis of four locking situations for different client threads:
Situation 1: Add the read lock first and then add the read lock, not mutually exclusive
Situation 2: Add read lock first and write lock, mutually exclusive
Situation 3: Add a write lock first and then a read lock, mutually exclusive
Situation 4: Add a write lock first and then add a write lock, mutually exclusive
Next, analyze four locking situations of the same client thread:
Situation 1: Add the read lock first and then add the read lock, not mutually exclusive
Situation 2: Add read lock first and write lock, mutually exclusive
Situation 3: Add a write lock first and then a read lock, not mutually exclusive
Situation 4: Add a write lock first and then write lock, not mutually exclusive
It can be understood as follows: the write lock has a high priority and the read lock has a low priority. If the write lock with a high priority is added to the same thread first, then the read lock with a low priority can continue to be added. If the same thread first adds a read lock with a low priority, then the write lock with a high priority cannot be added. Generally, locks can be downgraded, but not upgraded.
(1) The same client thread first adds the read lock and then adds the read lock
When client A (UUID1:ThreadID1) adds a read lock first:
//Passed in parameters
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1
ARGV[3] = UUID1:ThreadID1:write
//Execution results
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1When client A (UUID1:ThreadID1) adds a read lock again, it is judged that it can be successfully added.
//Execute the command
hget myLock mode, mode=read is found, which means that the read lock has been added
hincrby myLock UUID1:ThreadID1 1
set {myLock}:UUID1:ThreadID1:rwlock_timeout:2 1
pexpire myLock 30000
pexpire {myLock}:UUID1:ThreadID1:rwlock_timeout:2 30000
//Execution results
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 2
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1(2) The same client thread first adds the read lock and then write lock
When client A (UUID1:ThreadID1) adds a read lock first:
//Passed in parameters
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1
ARGV[3] = UUID1:ThreadID1:write
//Execution results
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1When client A (UUID1:ThreadID1) adds a write lock again, the judgment fails and cannot be successful.
//Passed in parameters
KEYS[1] = myLock
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1:writeExecute the command "hget myLock mode" and find that mode = read is not met. Therefore, the same client thread will be mutually exclusive if it adds a read lock first and then a write lock.
(3) The same client thread first adds the write lock and then adds the read lock.
When client A (UUID1:ThreadID1) adds a write lock first:
//Passed in parameters
KEYS[1] = myLock
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1:write
//Execution results
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1
}When client A (UUID1:ThreadID1) adds a read lock again, the judgment is passed and the addition can be successful.
//Passed in parameters
KEYS[1] = myLock
KEYS[2] = {myLock}:UUID1:ThreadID1:rwlock_timeout
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1
ARGV[3] = UUID1:ThreadID1:write
//Execute the command
hget myLock mode, mode=write is found, which means that the write lock has been added
hexists myLock UUID1:ThreadID1:write, judge that the write lock is added by yourself, the conditions are true
hincrby myLock UUID1:ThreadID1 1, indicating that a read lock has been added at this time
set {myLock}:UUID1:ThreadID1:rwlock_timeout:1 1
pexpire myLock 30000
pexpire {myLock}:UUID1:ThreadID11:rwlock_timeout:1 30000
//Execution results
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1,
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1It can be seen that if it is the same client thread, add the write lock first and then add the read lock, which can be successfully added. Therefore, the default thread can add a read lock multiple times during the period when the thread holds a write lock.
(4) The same client thread first adds a write lock and then a write lock
When client A (UUID1:ThreadID1) adds a write lock first:
//Passed in parameters
KEYS[1] = myLock
ARGV[1] = 30000
ARGV[2] = UUID1:ThreadID1:write
//Execution results
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1
}When client A (UUID1:ThreadID1) adds a write lock again, the judgment is passed and the addition can be successful.
//Execute the command
hexists myLock UUID1:ThreadID1:write, determine whether it is a write lock added by yourself
hincrby myLock UUID1:ThreadID1:write 1
pexpire myLock 50000
//Execution results
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 2
}It can be seen that read and write locks are also a reentrant lock. If the same client thread writes the lock multiple times, it can reenter the lock. The first write lock can be reentered by the read lock, while the first read lock cannot be reentered by the write lock.
8. Release the read lock logic of RedissonReadLock
(1) RedissonReadLock release process
(2) Three main situations before releasing the read lock
(3) RedissonReadLock's lua script to release the read lock
(4) Execute the lua script for the merged situation one and two
(5) Execute the lua script for situation three
(1) RedissonReadLock release process
Release the read lock to call RedissonLock's unlock() method.
In the unlock() method of RedissonLock, get(unlockAsync()) code will be executed. That is, first call the unlockAsync() method of RedissonBaseLock, and then call the get() method of RedissonObject.
Among them, the unlockAsync() method is an asynchronous execution method, and the operation of releasing the lock is executed asynchronously. The get() method of RedisObject will wait to obtain the result of asynchronous execution through RFuture synchronization. Get(unlockAsync()) can be understood as asynchronous to synchronization.
In the unlockAsync() method of RedissonBaseLock: the reentrant lock will call the() method to release the lock asynchronously, and the read lock will call the unlockInnerAsync() method of RedissonReadLock to release the lock asynchronously. Then, after completing the process of releasing the lock, the timing scheduling task will be cancelled asynchronously.
public class Application {
public static void main(String[] args) throws Exception {
Config config = new Config();
().addNodeAddress("redis://192.168.1.110:7001");
//Read and write lock
RedissonClient redisson = (config);
RReadWriteLock rwlock = ("myLock");
().lock();//Acquiring the read lock
().unlock();//Release the read lock
().lock();//Acquire the write lock
().unlock();//Release the write lock
...
}
}
public class RedissonLock extends RedissonBaseLock {
...
@Override
public void unlock() {
...
//Asynchronous to synchronous
//The first call is the unlockAsync() method of RedissonBaseLock
//Then the call is the get() method of RedissonObject
get(unlockAsync(().getId()));
...
}
...
}
public abstract class RedissonBaseLock extends RedissonExpirable implements RLock {
...
@Override
public RFuture<Void> unlockAsync(long threadId) {
//Asynchronously execute the lua script that releases the lock
RFuture<Boolean> future = unlockInnerAsync(threadId);
CompletionStage<Void> f = ((opStatus, e) -> {
//Cancel the scheduled task
cancelExpirationRenewal(threadId);
if (e != null) {
throw new CompletionException(e);
}
if (opStatus == null) {
IllegalMonitorStateException cause = new IllegalMonitorStateException("attempt to unlock lock, not locked by current thread by node id: " + id + " thread-id: " + threadId);
throw new CompletionException(cause);
}
return null;
});
return new CompleteFutureWrapper<>(f);
}
protected abstract RFuture<Boolean> unlockInnerAsync(long threadId);
...
}
public class RedissonReadLock extends RedissonLock implements RLock {
...
@Override
protected RFuture<Boolean> unlockInnerAsync(long threadId) {
String timeoutPrefix = getReadWriteTimeoutNamePrefix(threadId);
String keyPrefix = getKeyPrefix(threadId, timeoutPrefix);
return evalWriteAsync(getRawName(), RedisCommands.EVAL_BOOLEAN,
"...",
Arrays.<Object>asList(getRawName(), getChannelName(), timeoutPrefix, keyPrefix),
LockPubSub.UNLOCK_MESSAGE,
getLockName(threadId)
);
}
...
}(2) Three main situations before releasing the read lock
Situation 1: Different client threads have added read locks
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1,
"UUID2:ThreadID2": 1,
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1Situation 2: The same client thread reenters multiple times to read lock
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 2
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1Situation 1 can be merged with Situation 2:
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 2,
"UUID2:ThreadID2": 1,
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1Situation 3: The same client thread first adds a write lock and then adds a read lock
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1,
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1(3) RedissonReadLock's lua script to release the read lock
public class RedissonReadLock extends RedissonLock implements RLock {
...
@Override
protected RFuture<Boolean> unlockInnerAsync(long threadId) {
String timeoutPrefix = getReadWriteTimeoutNamePrefix(threadId);
String keyPrefix = getKeyPrefix(threadId, timeoutPrefix);
return evalWriteAsync(getRawName(), RedisCommands.EVAL_BOOLEAN,
//Execute the command "hget myLock mode"
"local mode = ('hget', KEYS[1], 'mode'); " +
// If mode is false, publish a message
"if (mode == false) then " +
"('publish', KEYS[2], ARGV[1]); " +
"return 1; " +
"end; " +
//Execute the command "hexists myLock UUID1:ThreadIdD1" to determine whether the corresponding Hash value of the current thread exists
"local lockExists = ('hexists', KEYS[1], ARGV[2]); " +
"if (lockExists == 0) then " +
"return nil;" +
"end; " +
//Execute the command "hincrby myLock UUID1:ThreadID1 -1" to decrement the corresponding Hash value of the current thread
"local counter = ('hincrby', KEYS[1], ARGV[2], -1); " +
"if (counter == 0) then " +
"('hdel', KEYS[1], ARGV[2]); " +
"end;" +
//For example, execute "del {myLock}:UUID1:ThreadId1:rwlock_timeout:2"
//Delete a reentry read lock of the current client thread UUID1:ThreadId1;
"('del', KEYS[3] .. ':' .. (counter+1)); " +
//Execute the command "hlen myLock > 1" to determine whether there are more than 1 element in the Hash
"if (('hlen', KEYS[1]) > 1) then " +
"local maxRemainTime = -3; " +
//Get all keys whose key is the Hash value of the lock name
"local keys = ('hkeys', KEYS[1]); " +
//Transf the keys to get the maximum remaining expiration time for these reentrant and non-reentrant read locks
"for n, key in ipairs(keys) do " +
"counter = tonumber(('hget', KEYS[1], key)); " +
//Exclude kv pairs with key as mode
"if type(counter) == 'number' then " +
//Reenter the key of the lock by decreasing splicing
"for i=counter, 1, -1 do " +
"local remainTime = ('pttl', KEYS[4] .. ':' .. key .. ':rwlock_timeout:' .. i); " +
"maxRemainTime = (remainTime, maxRemainTime);" +
"end; " +
"end; " +
"end; " +
// After finding the maximum remaining expiration time of all reentrant and non-reentrant read locks, the expiration time of the lock is reset to this time
"if maxRemainTime > 0 then " +
"('pexpire', KEYS[1], maxRemainTime); " +
"return 0; " +
"end;" +
"if mode == 'write' then " +
"return 0;" +
"end; " +
"end; " +
//Delete the lock
"('del', KEYS[1]); " +
//Posted an event
"('publish', KEYS[2], ARGV[1]); " +
"return 1; ",
//KEYS[1] = myLock, indicating the name of the lock
//KEYS[2] = redisson_rwlock:{myLock}, used for Redis publish subscription
//KEYS[3] = {myLock}:UUID1:ThreadID1:rwlock_timeout
//KEYS[4] = {myLock}
Arrays.<Object>asList(getRawName(), getChannelName(), timeoutPrefix, keyPrefix),
LockPubSub.UNLOCK_MESSAGE,//ARGV[1] = 0, indicating the publish event type
getLockName(threadId)//ARGV[2] = UUID1:ThreadID1, indicating the key represented by the client thread in the lock
);
}
...
}Parameter description:
KEYS[1] = myLock, indicating the name of the lock
KEYS[2] = redisson_rwlock:{myLock}, used for public subscriptions for Redis
KEYS[3] = {myLock}:UUID1:ThreadID1:rwlock_timeout
KEYS[4] = {myLock}
ARGV[1] = 0, indicating the type of publishing event
ARGV[2] = UUID1:ThreadID1, which indicates the key represented by the client thread in the lock.(4) Execute the lua script for the merged situation one and two
1. Client A (UUID1:ThreadID1) releases the read lock first
2. Client A (UUID1:ThreadID1) releases the read lock again
3. Client B (UUID2:ThreadID2) releases the read lock again
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 2,
"UUID2:ThreadID2": 1,
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID1:ThreadID1:rwlock_timeout:2 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 11. Client A (UUID1:ThreadID1) releases the read lock first
First, execute the command "hget myLock mode" and find mode = read. Then execute the command "hexists myLock UUID1:ThreadIdD1" and find that it must exist because the client thread UUID1:ThreadIdD1 has added a read lock.
Then execute the command "hincrby myLock UUID1:ThreadID1 -1" to decrement the number of read locks corresponding to this client thread by 1, and the counter changes from 2 to 1. When the counter is greater than 1, it means that the thread still holds the read lock. Then execute "del {myLock}:UUID1:ThreadId1:rwlock_timeout:2", which means deleting the key used to record the second reentry lock expiration time of the current client thread.
At this time, the data of myLock lock becomes as follows:
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1,
"UUID2:ThreadID2": 1,
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 1Then execute the command "hlen myLock" to determine whether there are more than 1 element in the Hash. If more than 1, then iterates over all reentrant and non-reentrant read locks that have been acquired by the thread, that is, iterates over all keys like "{myLock}:UUID2:ThreadID2:rwlock_timeout:1".
Then execute the command "pttl {myLock}:UUID1:ThreadID1:rwlock_timeout:1". That is, obtain the remaining expiration time of each reentry read lock and non-reentry read lock, and find the largest one. Execute "pexpire myLock" to reset the expiration time of the read lock to the maximum remaining expiration time.
2. Client A (UUID1:ThreadID1) releases the read lock again
First, execute the command "hincrby myLock UUID1:ThreadID1 -1" to decrement the number of read locks corresponding to this client thread by 1, and counter changes from 1 to 0. When counter=0, execute the command "hdel myLock UUID1:ThreadID1", which means delete the key used to record the number of locks reentered by the client thread.
Then execute the command "del {myLock}:UUID1:ThreadID1:rwlock_timeout:1", which means deleting the key used to record the first reentry lock expiration time of the current client thread. Finally, get the remaining expiration time for each reentry and non-reentry read lock and find the largest of them. Execute "pexpire myLock" to reset the expiration time of the read lock to the maximum remaining expiration time.
At this time, the data of myLock lock becomes as follows:
//Hash structure
myLock: {
"mode": "read",
"UUID2:ThreadID2": 1,
}
//String structure
{myLock}:UUID2:ThreadID2:rwlock_timeout:1 ==> 13. Client B (UUID2:ThreadID2) releases the read lock again
First, execute the command "hincrby myLock UUID2:ThreadID2 -1" to decrement the number of read locks corresponding to this client thread by 1, and counter changes from 1 to 0. Then execute the command "hdel myLock UUID2:ThreadID2", which means deleting the key used to record the number of locks reentered by the client thread. Then execute the command "del {myLock}:UUID1:ThreadID1:rwlock_timeout:1", which means deleting the key used to record the first reentry lock expiration time of the current client thread.
At this time, the data of myLock lock becomes as follows:
//Hash structure
myLock: {
"mode": "read"
}At this time, continue to execute the command "hlen myLock", and find that it is 1, and the judgment is not passed, so execute "del myLock". That is, when no thread holds this read lock, the read lock will be completely deleted and an event will be published.
(5) Execute the lua script for situation three
This situation is: the same client thread first adds a write lock and then adds a read lock. At this time, the data of myLock lock is as follows:
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1,
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1First, execute the command "hincrby myLock UUID1:ThreadID1 -1" to decrement the number of read locks corresponding to this client thread by 1, and counter changes from 1 to 0. Then execute the command "hdel myLock UUID1:ThreadID1", which means deleting the key used to record the number of locks reentered by the client thread. Then execute "del {myLock}:UUID1:ThreadID1:rwlock_timeout:1", that is, delete the key used to record the first reentry lock expiration time of the current client thread.
At this time, the data of myLock lock becomes as follows:
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 1
}Then execute the command "hlen myLock > 1" to determine whether there are more than 1 element in the Hash. It is found that the judgment is passed, but since there is no read lock, it will finally be judged that mode is write and returns 0.
9. Write lock RedissonWriteLock release write lock logic
(1) There are two main situations before releasing the write lock
(2) RedissonWriteLock's release write lock lua script
(3) Execute the lua script that releases the write lock
(1) There are two main situations before releasing the write lock
Situation 1: The same client thread reenters the write lock multiple times
Situation 2: The same client thread first adds a write lock and then adds a read lock
The lock data in these two cases can be combined into the following:
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1:write": 2,
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1Next, lua script analysis is performed based on this lock data.
(2) RedissonWriteLock's release write lock lua script
public class RedissonWriteLock extends RedissonLock implements RLock {
...
@Override
protected RFuture<Boolean> unlockInnerAsync(long threadId) {
return evalWriteAsync(getRawName(), RedisCommands.EVAL_BOOLEAN,
//First execute the command "hget myLock mode" and find mode=write
"local mode = ('hget', KEYS[1], 'mode'); " +
"if (mode == false) then " +
"('publish', KEYS[2], ARGV[1]); " +
"return 1; " +
"end;" +
"if (mode == 'write') then " +
//Then execute the command "hexists myLock UUID1:ThreadIdD1:write" and find that there is
"local lockExists = ('hexists', KEYS[1], ARGV[3]); " +
"if (lockExists == 0) then " +
"return nil;" +
"else " +
//So then execute the command "hincrby myLock UUID1:ThreadID1:write -1"
"local counter = ('hincrby', KEYS[1], ARGV[3], -1); " +
"if (counter > 0) then " +
//When the counter is greater than 0, it means that there is still a thread holding a write lock, then reset the expiration time of the lock
"('pexpire', KEYS[1], ARGV[2]); " +
"return 0; " +
"else " +
//When counter is 0, execute the command "hdel myLock UUID1:ThreadID1:write"
"('hdel', KEYS[1], ARGV[3]); " +
//Discern whether there are more than 1 element in Hash with key as lock name
"if (('hlen', KEYS[1]) == 1) then " +
//If there is only 1, it means that no thread holds the lock. At this time, you can delete the corresponding key of the lock
"('del', KEYS[1]); " +
"('publish', KEYS[2], ARGV[1]); " +
"else " +
//If there are more than 1, it means that there is still a thread holding a read lock. At this time, the write lock needs to be transferred to the read lock.
"('hset', KEYS[1], 'mode', 'read'); " +
"end; " +
"return 1; "+
"end; " +
"end; " +
"end; " +
"return nil;",
//KEYS[1] = myLock, KEYS[2] = redisson_rwlock:{myLock}
Arrays.<Object>asList(getRawName(), getChannelName()),
LockPubSub.READ_UNLOCK_MESSAGE,//ARGV[1] = 0
internalLockLeaseTime,//ARGV[2] = 30000
getLockName(threadId)//ARGV[3] = UUID1:ThreadID1:write
);
}
...
}(3) Execute the lua script that releases the write lock
1. Parameter description
KEYS[1] = myLock
KEYS[2] = redisson_rwlock:{myLock}
ARGV[1] = 0
ARGV[2] = 30000
ARGV[3] = UUID1:ThreadID1:write2. Lua script execution analysis
First, execute the command "hget myLock mode" and find that mode = write. Then execute the command "hexists myLock UUID1:ThreadIdD1:write" and find that it exists. So, the command "hincrby myLock UUID1:ThreadID1:write -1" is executed, which means decrementing the number of write locks corresponding to this client thread by 1, and the counter changes from 2 to 1. When the counter is greater than 0, it means that there is still a thread holding the write lock, and then the expiration time of the lock is reset. When counter is 0, execute the command "hdel myLock UUID1:ThreadID1:write", which deletes the key used to record the number of write locks of the current client thread reentered.
After deletion, myLock's lock data is as follows:
//Hash structure
myLock: {
"mode": "write",
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1Then execute the command "hlen myLock" to determine whether there are more than 1 element in the Hash whose key is the lock name. If there is only 1, it means that no thread holds the lock. At this time, you can delete the corresponding key of the lock. If there are more than 1, it means that there is still thread holding a read lock, and the write lock needs to be transferred to the read lock.
Therefore, the lock data of myLock in the end is as follows:
//Hash structure
myLock: {
"mode": "read",
"UUID1:ThreadID1": 1
}
//String structure
{myLock}:UUID1:ThreadID1:rwlock_timeout:1 ==> 1