redisson lock、tryLock分布式锁原理解析
redisson lock、tryLock分布式锁原理解析
·
近期在处理程序有两个不同来源入口的时候，因为容易产生并发情况，造成会有脏数据产生，在同事推荐下使用redisson的锁来解决并发问题。
先上使用的一定程度封装的工具类：
工具类
@Service
public class RedissonManager {
@Autowired
private RedissonClient redissonClient;
/**
* 加锁
*
* @param lockKey
* @return
*/
public RLock lock(String lockKey) {
RLock lock = redissonClient.getLock(lockKey);
lock.lock();
return lock;
}
/**
* 释放锁
*
* @param lockKey
*/
public void unlock(String lockKey) {
RLock lock = redissonClient.getLock(lockKey);
lock.unlock();
}
/**
* 释放锁
*
* @param lock
*/
public void unlock(RLock lock) {
lock.unlock();
}
/**
* 带超时的锁
*
* @param lockKey
* @param timeout 超时时间 单位：秒
*/
public RLock lock(String lockKey, int timeout) {
RLock lock = redissonClient.getLock(lockKey);
lock.lock(timeout, TimeUnit.SECONDS);
return lock;
}
/**
* 带超时的锁
*
* @param lockKey
* @param unit 时间单位
* @param timeout 超时时间
*/
public RLock lock(String lockKey, TimeUnit unit, int timeout) {
RLock lock = redissonClient.getLock(lockKey);
lock.lock(timeout, unit);
return lock;
}
/**
* 尝试获取锁
*
* @param lockKey
* @param waitTime 最多等待时间
* @param leaseTime 上锁后自动释放锁时间
* @return
*/
public boolean tryLock(String lockKey, int waitTime, int leaseTime) {
RLock lock = redissonClient.getLock(lockKey);
try {
return lock.tryLock(waitTime, leaseTime, TimeUnit.SECONDS);
} catch (InterruptedException e) {
return false;
}
}
/**
* 尝试获取锁
*
* @param lockKey
* @param unit 时间单位
* @param waitTime 最多等待时间
* @param leaseTime 上锁后自动释放锁时间
* @return
*/
public boolean tryLock(String lockKey, TimeUnit unit, int waitTime, int leaseTime) {
RLock lock = redissonClient.getLock(lockKey);
try {
return lock.tryLock(waitTime, leaseTime, unit);
} catch (InterruptedException e) {
return false;
}
}
}
实际使用很简单，就是直接使用方法来锁住一个key，但是后续测试发现lock和tryLock是两种不同的情况。
lock是当获取锁失败时会阻塞当前进程，如果没有带参数设置过期时间则是30秒后自动解锁。
tryLock则是当获取锁失败时，当超过设置的等待时间时返回false
后面楼主出于好奇便看了一下redisson源码以及结合网上大神的见解，略为理解了一下，以此记录一下个人见解（不对请大家积极指出）
lock
private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
// 此处为获取当前线程id
long threadId = Thread.currentThread().getId();
// 核心代码见下图后继续回来走逻辑
Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
// 此处得到获取锁的结果，正常获取锁则ttl为null，竞争锁时返回锁的过期时间
if (ttl == null) {
return;
}
// 此处为订阅锁释放事件，
// 如果当前线程通过 Redis 的 channel 订阅锁的释放事件获取得知已经被释放
// 则会发消息通知待等待的线程进行竞争.
RFuture<RedissonLockEntry> future = subscribe(threadId);
if (interruptibly) {
commandExecutor.syncSubscriptionInterrupted(future);
} else {
commandExecutor.syncSubscription(future);
}
try {
while (true) {
// 此处循环重试获取锁，直至重新获取锁成功才跳出循环，
// 此种做法阻塞进程，一直处于等待锁手动释放或者超时才继续线程
ttl = tryAcquire(-1, leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
break;
}
// waiting for message
if (ttl >= 0) {
try {
future.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
if (interruptibly) {
throw e;
}
future.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
}
} else {
if (interruptibly) {
future.getNow().getLatch().acquire();
} else {
future.getNow().getLatch().acquireUninterruptibly();
}
}
}
} finally {
// 最后释放订阅事件
unsubscribe(future, threadId);
}
// get(lockAsync(leaseTime, unit));
}
tryLockInnerAsync
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
"if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"return redis.call('pttl', KEYS[1]);",
Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
}
此段脚本为一段lua脚本：
结合个人理解其中的变量参数：
KEY[1]: 为你加锁的lock值
ARGV[2]: 为线程id
ARGV[1]: 为设置的过期时间
第一个if：
判断是否存在设置lock的key是否存在，不存在则利用redis的hash结构设置一个hash，值为1，并设置过期时间，后续返回锁。
第二个if：
判断是否存在设置lock的key是否存在，存在此线程的hash，则为这个锁的重入次数加1（将hash值+1），并重新设置过期时间，后续返回锁。
最后返回：
这个最后返回不是说最后结果返回，是代表以上两个if都没有进入，则代表处于竞争锁的情况，后续返回竞争锁的过期时间。
tryLock
trylock具有返回值，true或者false，表示是否成功获取锁。tryLock前期获取锁逻辑基本与lock一致，主要是后续获取锁失败的处理逻辑与lock不一致。
@Override
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
long time = unit.toMillis(waitTime);
long current = System.currentTimeMillis();
long threadId = Thread.currentThread().getId();
Long ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
return true;
}
// 以上与lock逻辑一致
// 获取锁失败后，中途tryLock会一直判断中间操作耗时是否已经消耗锁的过期时间，如果消耗完则返回false
time -= System.currentTimeMillis() - current;
if (time <= 0) {
acquireFailed(waitTime, unit, threadId);
return false;
}
current = System.currentTimeMillis();
// 此处为订阅锁释放事件，
// 如果当前线程通过 Redis 的 channel 订阅锁的释放事件获取得知已经被释放
// 则会发消息通知待等待的线程进行竞争.
RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
// 将订阅阻塞，阻塞时间设置为我们调用tryLock设置的最大等待时间，超过时间则返回false
if (!subscribeFuture.await(time, TimeUnit.MILLISECONDS)) {
if (!subscribeFuture.cancel(false)) {
subscribeFuture.onComplete((res, e) -> {
if (e == null) {
unsubscribe(subscribeFuture, threadId);
}
});
}
acquireFailed(waitTime, unit, threadId);
return false;
}
try {
time -= System.currentTimeMillis() - current;
if (time <= 0) {
acquireFailed(waitTime, unit, threadId);
return false;
}
// 循环获取锁，但由于上面有最大等待时间限制，基本会在上面返回false
while (true) {
long currentTime = System.currentTimeMillis();
ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
return true;
}
time -= System.currentTimeMillis() - currentTime;
if (time <= 0) {
acquireFailed(waitTime, unit, threadId);
return false;
}
// waiting for message
currentTime = System.currentTimeMillis();
if (ttl >= 0 && ttl < time) {
subscribeFuture.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
} else {
subscribeFuture.getNow().getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
}
time -= System.currentTimeMillis() - currentTime;
if (time <= 0) {
acquireFailed(waitTime, unit, threadId);
return false;
}
}
} finally {
unsubscribe(subscribeFuture, threadId);
}
// return get(tryLockAsync(waitTime, leaseTime, unit));
}
结论
尽量在自己代码逻辑中添加解锁的逻辑，避免锁长时间存在浪费不必要的资源
综上所述，应尽量使用tryLock，且携带参数，因为可设置最大等待时间以及可及时获取加锁返回值，后续可做一些其他加锁失败的业务
以上是个人理解，如有不对，希望各位大神指出修改
为开发者提供学习成长、分享交流、生态实践、资源工具等服务，帮助开发者快速成长。
更多推荐
12
0- 0
已为社区贡献1条内容
所有评论(0)