锁和分布式锁的一些理解

一、锁

1.自旋锁

自旋锁是一种非阻塞锁，也就是说，如果某线程需要获取自旋锁，但该锁已经被其他线程占用时，该线程不会被挂起，而是在不断的消耗CPU的时间，不停的试图获取自旋锁

2.互斥锁

互斥锁是阻塞锁，当某线程无法获取互斥锁时，该线程会被直接挂起，不再消耗CPU时间，当其他线程释放互斥锁后，操作系统会唤醒那个被挂起的线程。

阻塞锁可以说是让线程进入阻塞状态进行等待，当获得相应的信号（唤醒，时间）时，才可以进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争进入运行状态。它的优势在于，阻塞的线程不会占用 CPU 时间， 不会导致 CPU 占用率过高，但进入时间以及恢复时间都要比自旋锁略慢。在竞争激烈的情况下阻塞锁的性能要明显高于自旋锁。

JAVA中，能够进入/退出、阻塞状态或包含阻塞锁的方法有:synchronizedReentrantLockObject.wait()/notify()LockSupport.park()/unpart()(j.u.c经常使用)

自旋锁 vs 互斥锁

多核情况下，才会使用到自旋锁。

在多核情况下，如果线程切换的时间比线程等待的时间大，那么就用自旋锁。

3.可重入锁

sysnchronized 和 reentrantlock 都是可重入的。

二、分布式锁

1、数据库的分布式锁

乐观锁的version比较

2. redis实现的分布式锁

a. 基于setnx、expire两个命令来实现

基于setnx（set if not exist）的特点，当缓存里key不存在时，才会去set，否则直接返回false。如果返回true则获取到锁，否则获取锁失败，为了防止死锁，我们再用expire命令对这个key设置一个超时时间来避免。但是这里看似完美，实则有缺陷，当我们setnx成功后，线程发生异常中断，expire还没来的及设置，那么就会产生死锁。

解决上述问题有两种方案：

第一种是采用Redis 2.6.12版本以后的set，它提供了一系列选项

• EX seconds – 设置键key的过期时间，单位时秒
• PX milliseconds – 设置键key的过期时间，单位时毫秒
• NX – 只有键key不存在的时候才会设置key的值
• XX – 只有键key存在的时候才会设置key的值

第二种采用setnx()，get()，getset()实现，大体的实现过程如下：

(1) 线程Asetnx，值为超时的时间戳(t1)，如果返回true，获得锁。

(2) 线程B用get 命令获取t1，与当前时间戳比较，判断是否超时，没超时false，如果已超时执行步骤3

(3) 计算新的超时时间t2，使用getset命令返回t3(这个值可能其他线程已经修改过)，如果t1==t3,获得锁,如果t1!=t3说明锁被其他线程获取了

(4) 获取锁后，处理完业务逻辑，再去判断锁是否超时，如果没超时删除锁，如果已超时，不用处理（防止删除其他线程的锁）

b. RedLock算法

RedLock算法是Redis作者推荐的一种分布式锁实现方式，算法的内容如下：

(1) 获取当前时间；

(2) 尝试从5个相互独立Redis客户端获取锁；

(3) 计算获取所有锁消耗的时间，当且仅当客户端从多数节点获取锁，并且获取锁的时间小于锁的有效时间，认为获得锁；

(4) 重新计算有效期时间，原有效时间减去获取锁消耗的时间；

(5) 删除所有实例的锁

RedLock算法相对于单节点Redis锁可靠性要更高，但是实现起来条件也较为苛刻。

(1) 必须部署5个节点才能让RedLock的可靠性更强。

(2) 需要请求5个节点才能获取到锁，通过Future的方式，先并发向5个节点请求，再一起获得响应结果，能缩短响应时间，不过还是比单节点Redis锁要耗费更多时间。

然后由于必须获取到5个节点中的3个以上，所以可能出现获取锁冲突，即大家都获得了1-2把锁，结果谁也不能获取到锁，这个问题，Redis作者借鉴了Raft算法的精髓，通过冲突后在随机时间开始，可以大大降低冲突时间，但是这问题并不能很好的避免，特别是在第一次获取锁的时候，所以获取锁的时间成本增加了。

如果5个节点有2个宕机，此时锁的可用性会极大降低，首先必须等待这两个宕机节点的结果超时才能返回，另外只有3个节点，客户端必须获取到这全部3个节点的锁才能拥有锁，难度也加大了。

如果出现网络分区，那么可能出现客户端永远也无法获取锁的情况，介于这种情况，下面我们来看一种更可靠的分布式锁ZooKeeper锁。

3.ZooKeeper分布式锁

首先我们来了解一下ZooKeeper的特性，看看它为什么适合做分布式锁，ZooKeeper是一个为分布式应用提供一致性服务的软件，它内部是一个分层的文件系统目录树结构，规定统一个目录下只能有一个唯一文件名。

数据模型：

• 永久节点：节点创建后，不会因为会话失效而消失
• 临时节点：与永久节点相反，如果客户端连接失效，则立即删除节点
• 顺序节点：与上述两个节点特性类似，如果指定创建这类节点时，zk会自动在节点名后加一个数字后缀，并且是有序的。

监视器（watcher）：

• 当创建一个节点时，可以注册一个该节点的监视器，当节点状态发生改变时，watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次。

根据ZooKeeper的这些特性，我们来看看如何利用这些特性来实现分布式锁：

1. 创建一个锁目录lock

2. 希望获得锁的线程A就在lock目录下，创建临时顺序节点

3. 获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁

4. 线程B获取所有节点，判断自己不是最小节点，设置监听(watcher)比自己次小的节点（只关注比自己次小的节点是为了防止发生“羊群效应”）

5. 线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是最小的节点，获得锁。