Java多线程开发中锁提供了原子性、可见性。但是在分布式系统中，一个进程下的多个线程分布到一个集群中的多台机器上，需要其他方式来保证原子性、可见性。通过封装Redis的SETNX命令，可以实现分布式锁，提供分布式环境下的原子性。
测试代码
测试代码启动三个名称为test-1、test-2、test-3线程，线程内部会对同一个静态变量执行一万次++操作，如果代码正确，最终静态变量的值应该为3万。测试代码如下：
public class LockTest {
public static int i = 0;
public static void main(String[] args) throws InterruptedException {
CountDownLatch countDownLatch = new CountDownLatch(3);
CyclicBarrier cyclicBarrier = new CyclicBarrier(3);
new Thread(new CountRunnable(countDownLatch, cyclicBarrier), "test-1").start();
new Thread(new CountRunnable(countDownLatch, cyclicBarrier), "test-2").start();
new Thread(new CountRunnable(countDownLatch, cyclicBarrier), "test-3").start();
countDownLatch.await();
System.out.println(LockTest.i);
}
static class CountRunnable implements Runnable{
private CountDownLatch countDownLatch;
private CyclicBarrier cyclicBarrier;
public CountRunnable(CountDownLatch countDownLatch, CyclicBarrier cyclicBarrier){
this.countDownLatch = countDownLatch;
this.cyclicBarrier = cyclicBarrier;
}
@Override
public void run() {
try {
cyclicBarrier.await();
} catch (Exception e) {
e.printStackTrace();
}
for(int j = 0; j < 10000; j++){
LockTest.i++;
}
countDownLatch.countDown();
}
}
}
在不使用锁的情况下，执行三次输出结果分别为：24404、21768、17539。
简单版本
SETNX命令只有当key不存在时才能设值成功，返回值为1；key存在设值失败，返回0。根据命令特性，可以有以下实现：
public class SimpleRedisLock {
public static ThreadLocal<Jedis> holder = new ThreadLocal<>();
public static JedisPool jedisPool = new JedisPool(new JedisPoolConfig(), "localhost");
public static void acquire(String lock){
Jedis jedis = jedisPool.getResource();
while(jedis.setnx(lock, "") == 0){}
holder.set(jedis);
}
public static void release(String lock){
Jedis jedis = holder.get();
jedis.del(lock);
jedis.close();
}
}
在acquire方法内部，获取jedis对象，循环设置某个key的值，直到设置成功。release方法中删除这个key，代表释放锁。修改LockTest代码：
for(int j = 0; j < 10000; j++){
SimpleRedisLock.acquire("lock");
LockTest.i++;
SimpleRedisLock.release("lock");
}
重新执行测试代码，输入值：30000。
简单版本的问题
测试代码中启动了3个线程竞争同一个分布式锁，如果三个线程中，有任意一个线程在调用SimpleRedisLock的acquire成功之后异常退出，没有释放锁，另外两个线程会死循环等待在SETNX命令上，简单修改一下LockTest，模拟test-1异常退出的情况：
@Override
public void run() {
try {
cyclicBarrier.await();
for(int j = 0; j < 10000; j++){
SimpleRedisLock.acquire("lock");
if(Thread.currentThread().getName().equals("test-1")){
throw new RuntimeException();
}
LockTest.i++;
SimpleRedisLock.release("lock");
}
} catch (Exception e) {
e.printStackTrace();
}finally {
countDownLatch.countDown();
}
}
线程test-�1在获取到分布式锁之后，因为运行时异常退出（也有可能是因为进程、机器crash，OOM等各种问题），没有正确的释放锁，导致线程test-2、test-3死循环执行SETNX命令。
解决死锁问题
按照Redis文档给出的一种解决方法，重新修改acquire方法：
public static void acquire(String lock){
Jedis jedis = jedisPool.getResource();
//1.先尝试用setnx命令获取锁,key为参数lock,值为当前时间+要持有锁的时间hold_time
while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
//2.如果获取失败,检查lock对应的值是否已超时
String expireTime = jedis.get(lock);
if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//3.如果已经超时了,使用getset命令,设置新的超时时间
String oldExpire = jedis.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//4.如果setget命令返回的值,依然是过期时间,认为获取锁成功
break;
}
}
}
holder.set(jedis);
}
测试代码执行结果：
在test-1线程退出后，程序正常执行，并得到了正确结果2万。但这个版本依旧有两个问题没有解决:
test-1线程异常退出，test-2、test-3线程同时执行setnx失败，获取expireTime，发现已经小于currentTime，开始执行getset命令。假设test-2先执行了getset，获取锁成功。test-3线程在执行getset时，返回的是test-2设置的未超时的时间戳，是一个未超时的时间，获取锁失败。功能上没有问题，但test-2线程持有的锁的有效期时间戳已经被test-3修改了。
如果test-2线程在持有锁的期间，因为网络抖动等原因，操作（测试代码中对应++操作部分）还没有完成，但锁已经超时了。 如何确定是否要释放锁（即使客户端记录自己的超时时间戳也没用，问题1中已经描述了时间戳被其他线程修改的情况）？在需要互斥访问资源的场景，执行时间超过锁超时时间的情况下，怎么解决多个节点同时访问资源的情况（同时执行++操作）？
解决问题
重新修改获取锁的代码：
public class SimpleRedisLock {
public static long hold_time = 3000;
public static ThreadLocal<Jedis> holder = new ThreadLocal<>();
public static ThreadLocal<String> expireHolder = new ThreadLocal<>();
public static JedisPool jedisPool = new JedisPool(new JedisPoolConfig(), "localhost");
public static void acquire(String lock){
Jedis jedis = jedisPool.getResource();
//1.先尝试用setnx命令获取锁,key为参数lock,值为当前时间+要持有锁的时间hold_time
while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
//2.如果获取失败,先watch lock key
jedis.watch(lock);
//3.获取当前超时时间
String expireTime = jedis.get(lock);
if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//4.如果超时时间小于当前时间,开事务准备更新lock值
Transaction transaction = jedis.multi();
Response<String> response = transaction.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
//5.步骤2设置了watch,如果lock的值被其他线程修改,不是执行事务中的命令
if(transaction.exec() != null){
String oldExpire = response.get();
if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//6.如果setget命令返回的值依然是过期时间,认为获取锁成功(加了watch之后,这里返回的应该一直是超时时间)
break;
}
}
}else{
//如果key未超时,解除watch
jedis.unwatch();
}
}
//设置客户端超时时间
expireHolder.set(jedis.get(lock));
holder.set(jedis);
}
public static void release(String lock){
Jedis jedis = holder.get();
//比较客户端超时时间与lock值,判断是否还由自己持有锁
if(jedis.get(lock).equals(expireHolder.get())){
jedis.del(lock);
}
jedis.close();
}
}
新的acquire方法，通过watch、redis事务，保证只有一个客户端能执行getset，并记录了锁超时时间，解决了问题一和问题二的前半部分。对于锁超时导致的两个客户端同时访问资源，只能靠业务代码保证锁超时时间内可以完成处理（可以在release时检查是否超时，如果超时回滚所有操作，但对不能回滚的，例如++操作就比较麻烦），或者放弃死锁容错功能，需要看场景衡量。
代码 ：SimpleRedisLock
扩展
以上只是单点redis服务器情况下的分布式锁。在redis master-slaver架构下，如果master节点down机，由于redis主从复制是异步的，会有明显的race-condition。Redis文档中提供了一种解决方案：RedLock。
