根据场景设计Redis分布式锁的思考

   上一次说完了Redisson锁的优缺点，这节我们来看一下setnx命令封装的分布式锁

   

redisTemplate.opsForValue().setIfAbsent("lockname","data",60, TimeUnit.MILLISECONDS);

    ok,这句代码相信很多同学都不陌生，这么写在百分之90多的情况看起来没有什么问题，但是仔细思考下呢？

   1 :它具有可重入性吗？

       在执行setnx命令时，通常采用业务上指定的名称作为key名，用时间或随机值作为value来实现。它相对于RedissonLock，这样的实现方式不具备追踪请求 线程的能力，同时也不具备统计重入次数的能力，甚至有些实现方式都不具备操作的原子性。当遇到业务上需要在多个地方用到同样一个锁的时候，很显然使用不具有可重入的锁会很容易发生死锁的现象。特别是在有递归逻辑的场景里，发生死锁的几率会更高。所以呢，这个命令实现的分布式锁不具备可重入性。友情提醒，在单机环境下，我们都知道Java并发工具包里的Lock对象和sychronized语块都具有可重入性的哟。

 2：它具备阻塞能力吗？

     多个线程同时访问一个不是同步的方法，显然他不是阻塞的嘛。我们在单机环境玩多线程的时候都知道保证线程的安全要加锁，那么锁都具备两个共性：一是互斥，二是阻塞。互斥性是指在任何时刻最多只能有一个线程获得通行的资格。阻塞性是指的在有竞争的情况下，未获取到资源的线程会停止继续操作，直到成功获取到资源或取消操作。那么通过这个名词解释，这个命令实现的锁只保证了互斥，但是并没有保证阻塞。

3:  它的有效时间的缺陷

      假如A线程处理完业务逻辑执行到要删除锁的时候，这时锁失效了，有效时间设置的太短了，那么我们就需要延长一下锁的有效时间。而太长了在出现程序宕机或业务节点挂掉时，其它节点需要等很长时间才能恢复，而难以保证业务的可用性。这就导致了这个时间的极佳值的不确定性，太长不太好，太短又会出问题。setnx的设计缺乏一个延续有效期的续约机制，无法保证业务能够先工作做完再解锁，也不能确保在某个程序宕机或业务节点挂掉的时候，其它节点能够很快的恢复业务处理能力。而Redission的看门狗又优雅的恰恰弥补了它。

 

欢迎小伙伴们多多补充嗷。