前提
为何要使用分布式锁?
其实使用分布式锁的目的与平常使用synchronized锁，Lock锁的目的一致，就是为了确保多线程并发时，在某些业务场景中让这些线程串行执行。
通常在一个JVM中让线程串行执行是比较容易实现的，例如synchronized锁，Lock锁等。但是现在为了应对更大的并发量，通常会将服务拆分或者搭建集群，此时synchronized锁，Lock锁就无法让处于不同服务器中的线程互斥，或者说让处于不同JVM中的线程互斥。此时就需要使用分布式锁让这些不同服务中的线程互斥，从而串行执行。
那什么是分布式锁?
分布式锁:在分布式系统下或者集群模式下能够实现多个线程之间互斥并且可见。
分布式锁的思想就是让处于不同服务器中的线程共同使用同一把锁，从而保证这些线程在某些场景下串行执行
分布式锁有那些?
说到分布式锁其实还是有很多的，像mysql分布式锁，redis分布式锁，zookeeper分布式锁等
现在我们采用Redis作为分布式锁，那么将上述图片的中的两个监视器换为一个redis在外部，那么图片就形象生动的出现在脑海中，脑补
SETNX命令的特性
SETNX:向Redis中添加一个key，只用当key不存在的时候才添加并返回1，存在则不添加返回0。并且这个命令是原子性的。
使用SETNX作为分布式锁时，添加成功表示获取到锁，添加失败表示未获取到锁。至于添加的value值无所谓可以是任意值(根据业务需求)，只要保证多个线程使用的是同一个key，所以多个线程添加时只会有一个线程添加成功，就只会有一个线程能够获取到锁。而释放锁锁只需要将锁删除即可。
总结:
SETNX分布式锁
设置过期时间防止死锁
假设线程1通过SETNX获取到锁并且正常执行然后释放锁那么一切ok，其它线程也能获取到锁。但是线程1现在"耍脾气"了，线程1抱怨说"工作太久有点累需要休息一下，你们想要获取锁等着吧，等我把活干完你们再来获取锁"。此时其它线程就无法向下继续执行，因为锁在线程1手中。这种长期不释放锁情况就有可能造成死锁。
为了防止像线程1这种"耍脾气"的现象发生，我们可以设置key的过期时间来解决。设置过期时间过后其它线程可不会惯着线程1,其它线程表示你要休息可以，休息了指定时间把锁让出来然后拍拍屁股走人，没人惯着你。
Redis命令:
在添加时存在则添加，不存在则不添加。同时设置过期时间，单位秒SET key value NX EX time原命令及其参数 SET key value [NX | XX] [GET] [EX seconds | PX milliseconds | EXAT unix-time-seconds | PXAT unix-time-milliseconds | KEEPTTL]JAVA代码:
//通过java代码实现SETNX同时设置过期时间//key--键 value--值 time--过期时间 TimeUnit--时间单位枚举stringRedisTemplate.opsForValue().setIfAbsent(key, value , time, TimeUnit);SETNX分布式锁时误删情况
情况一
设置过期时间线程1被治得服服帖帖，此时线程1又开始不当人了。线程1想既然你抢我得锁，等你获得锁后我就将锁删除毕竟我还要有备用钥匙，让你也锁不住，让其它线程也执行。
线程1休息的时间超过了过期时间，此时锁会自动释放。线程2现在脱颖而出抢到了锁然后开心的继续执行。但是现在线程1醒了，发现线程2抢走了锁。线程1表示小子胆挺肥啊，敢抢我的锁，等我执行完了就将你锁删除，让其它"哥们"也进来。此时就会发生蝴蝶效应，线程1删除了线程2的锁，线程2删除了线程3的锁，直到最后一个"哥们：wc，我锁了?"。当然线程是无感知，其实线程1乃至其它线程都不知道删除的是别人的锁，全部线程都以为删除的是自己的锁。直到最后一个线程无锁可删。
这种误删锁的情况让锁的存在荡然无存，本来应该串行执行的线程，在一定程度上都开始并发执行了。
那么误删情况该如何解决了?
我们可以给锁加上线程标识，只有锁是当前线程的才能删除，否则不能删除。在添加key的时候，key的value存储当前线程的标识，这个标识只要保证唯一即可。可以使用UUID或者一个自增数据。在删除锁的时候，将线程标识取出来进行判断，如果相同就表示锁是自己的能够删除，否则不能删除。
获取锁:
//获取线程前缀，同时也是线程表示。通过UUID唯一性private static final String ID_PREFIX= UUID.randomUUID().toString(true)+"-";//与线程id组合public boolean tryLock(long timeOut) { //获取线程id String id =ID_PREFIX+ Thread.currentThread().getId(); //获取锁 Boolean absent = stringRedisTemplate.opsForValue().setIfAbsent(key, id , timeOut, TimeUnit.SECONDS); return Boolean.TRUE.equals(absent); }释放锁:
public void unLock() {//获取存储的线程标识 String value = stringRedisTemplate.opsForValue().get(key); //当前线程的线程标识 String id =ID_PREFIX+ Thread.currentThread().getId(); //线程标识相同则删除否,则不删除 if (id.equals(value)){ stringRedisTemplate.delete(key); } }情况二
加入线程标识后，线程一不能随便删除其它线程的锁，但是线程1又开始不当人了。线程1表示判断线程标识和释放锁的操作我可以分开执行，这又不是一个原子性的操作,线程1干完活以后就准备去释放锁，当线程1判断锁是自己的后表示开锁太累了,休息一会在开。此时其它线程就想无所谓，反正过期时间一到锁就会自动释放。但是线程1已经判断了锁是自己的以后就不会执行判断锁的操作(线程1已经执行了if判断，只是没有执行方法体),当线程2获得锁后，线程1仍然能删除线程2的锁。
特别说明:
public void unLock() { String value = stringRedisTemplate.opsForValue().get(key); //在此处发生垃圾回收,线程1暂停并且超过了过期时间，线程2先获得了锁 String id =ID_PREFIX+ Thread.currentThread().getId(); if (id.equals(value)){ //在此处发生垃圾回收,线程1暂停并且超过了过期时间，线程2先获得锁 stringRedisTemplate.delete(key); } }此时就需要将判断锁的操作和删除锁的操作作为一个整体执行，要么全部成功，要么全部失败，保证删除锁的原子性。
Lua脚本解决多条命令原子性问题
关于Lua语言参考此链接:Lua
导致线程1删除线程2锁的原因就是判断锁和删除锁的操作不是原子性的。此时可以使用Lua脚本保证多条命令的原子性。
Redis提供的函数：
redis.call('命令名称', 'key', '其它参数', ...)例如:redis.call('set','name','jack')---->set name jackLua脚本: 会将key存储在KEYS数组中，会将value存储在ARVG数组中。下标从1开始
if (redis.call('get',KEYS[1])==ARGV[1]) then return redis.call('DEL',KEYS[1])end return 0JAVA:通过execute()方法执行Lua脚本,DefaultRedisScript加载脚本
private static final DefaultRedisScript<Long> DEFAULT_REDIS_SCRIPT; static { DEFAULT_REDIS_SCRIPT=new DefaultRedisScript<Long>(); DEFAULT_REDIS_SCRIPT.setLocation(new ClassPathResource("unlock.lua")); DEFAULT_REDIS_SCRIPT.setResultType(Long.class); } public void unLock() { stringRedisTemplate.execute(DEFAULT_REDIS_SCRIPT, Collections.singletonList(RedisConstants.KEY_PREFIX + name),ID_PREFIX+ Thread.currentThread().getId()); }最后
文中提及SETNX作为分布式锁的原理以及存在的问题都是学习过程中的总结。
SETNX分布锁锁存在的问题: