转载

关于网上一个jedisLock锁问题的探讨

前言

前段时间项目有关redis分布式锁的代码经常出现锁超时的情况，经排查终于发现了个隐藏的问题，现记录下来以备忘。

问题复现

引用的jedis锁项目是

<groupId>com.github.jedis-lock</groupId>
 <artifactId>jedis-lock</artifactId>
 <version>1.0.0</version>

项目很简单，就一个java类，为描述清楚，我把它简要改造（不影响原义）复制下

public class JedisLock {

 Jedis jedis;

 String lockKey;


 int expireMsecs = 60 * 1000;


 int timeoutMsecs = 10 * 1000;

 boolean locked = false;


 public JedisLock(Jedis jedis, String lockKey) {
 this.jedis = jedis;
 this.lockKey = lockKey;
 }

 public String getLockKey() {
 return lockKey;
 }
 
 public synchronized boolean acquire() throws InterruptedException {
 int timeout = timeoutMsecs;
 while (timeout >= 0) {
 long expires = System.currentTimeMillis() + expireMsecs + 1;
 String expiresStr = String.valueOf(expires);

 if (jedis.setnx(lockKey, expiresStr) == 1) {
 // lock acquired
 locked = true;
 return true;
 }

 String currentValueStr = jedis.get(lockKey);
 if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
 // lock is expired

 String oldValueStr = jedis.getSet(lockKey, expiresStr);
 if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
 // lock acquired
 locked = true;
 return true;
 }
 }

 timeout -= 100;
 Thread.sleep(100);
 }

 return false;
 }


 public synchronized void release(Jedis jedis) {
 if (locked) {
 jedis.del(lockKey);
 locked = false;
 }
 }
}

项目里依赖的一个子项目引用了这个锁实现，并对这个类简单进行了封装。当时的问题是，据此实现的redis锁时不时就会有超时情况，查看日志发现，如有2个线程同时去获取锁，第2个线程会报超时，第1个线程直到第2个线程超时才继续执行。下面是简化业务后的测试用例

public class JedisLock {

 Jedis jedis;

 String lockKey;


 int expireMsecs = 60 * 1000;


 int timeoutMsecs = 10 * 1000;

 boolean locked = false;


 public JedisLock(Jedis jedis, String lockKey) {
 this.jedis = jedis;
 this.lockKey = lockKey;
 }

 public String getLockKey() {
 return lockKey;
 }
 
 public synchronized boolean acquire() throws InterruptedException {
 int timeout = timeoutMsecs;
 while (timeout >= 0) {
 long expires = System.currentTimeMillis() + expireMsecs + 1;
 String expiresStr = String.valueOf(expires);

 if (jedis.setnx(lockKey, expiresStr) == 1) {
 // lock acquired
 locked = true;
 return true;
 }

 String currentValueStr = jedis.get(lockKey);
 if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
 // lock is expired

 String oldValueStr = jedis.getSet(lockKey, expiresStr);
 if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
 // lock acquired
 locked = true;
 return true;
 }
 }

 timeout -= 100;
 Thread.sleep(100);
 }

 return false;
 }


 public synchronized void release(Jedis jedis) {
 if (locked) {
 jedis.del(lockKey);
 locked = false;
 }
 }
}

打印结果为

10:36:51.023 - Thread-1已获取到锁
10:36:53.028 - Thread-1释放锁
10:37:01.485 - Thread-2没有获取到锁
10:37:01.485 - Thread-1释放锁完成

根据打印结果我们能清楚看到，线程1获取到了锁，并在完成业务操作后去释放锁。可却一直没释放成功，直到线程2锁等待超时后，线程1才释放掉了锁。这个现象，倒是和日志描述的一致。

分析与解释

当时刚开始排查时，把重点放在业务代码的检查和加锁和解锁的代码上去了，后来通过简单复现才注意到，为什么线程1锁释放会阻塞住呢？这里也没什么操作啊，就是删除redis key值。debug发现线程1根本没进到release方法里面去。啊?这咋回事。考虑cpu满了也太牵强了，咋这么巧偏线程2超时退出了线程1就好了呢后来才注意到居然这里有个synchronized。再前后梳理下就全明白了。由于acquire和release都有synchronized修饰，在同一个对象（jedisLock）下，它们会有同一把对象锁。初始，线程1首先执行，进入acquire方法获取redis锁（这里线程1也会获取对象锁，不过执行完acquire方法h后对象锁就释放了）执行业务逻辑。此时线程2也进入acquire方法，获取到了对象锁，由于线程1此时在实现业务逻辑，所以线程2拿不到redis锁。它会一直在acquire方法中，不会释放对象锁此时线程1执行完业务逻辑，准备去释放redis锁，但是由于线程2占据了对象锁，所以它进不到release中，就此发生死锁，直到线程2获取redis锁超时退出acquire方法。怎么解决？最简单的就是线程的redisLock对象不是一个即可。也就是在线程里创建redislock对象。

 Runnable runnable = () -> {

 JedisLock jedisLock = new JedisLock(jedis, accessTokenKey);
 
 // 其他代码....
 jedisLock.acquire();
 // 其他代码....
 jedisLock.release(); 
 };

正文到此结束