一、锁
1.自旋锁
自旋锁是一种非阻塞锁,也就是说,如果某线程需要获取自旋锁,但该锁已经被其他线程占用时,该线程不会被挂起,而是在不断的消耗CPU的时间,不停的试图获取自旋锁
2.互斥锁
互斥锁是阻塞锁,当某线程无法获取互斥锁时,该线程会被直接挂起,不再消耗CPU时间,当其他线程释放互斥锁后,操作系统会唤醒那个被挂起的线程。
阻塞锁可以说是让线程进入阻塞状态进行等待,当获得相应的信号(唤醒,时间)时,才可以进入线程的准备就绪状态,准备就绪状态的所有线程,通过竞争进入运行状态。它的优势在于,阻塞的线程不会占用 CPU 时间, 不会导致 CPU 占用率过高,但进入时间以及恢复时间都要比自旋锁略慢。在竞争激烈的情况下阻塞锁的性能要明显高于自旋锁。
JAVA中,能够进入/退出、阻塞状态或包含阻塞锁的方法有: synchronized ReentrantLock Object.wait()/notify() LockSupport.park()/unpart()(j.u.c经常使用)
二、分布式锁
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的这些特性,我们来看看如何利用这些特性来实现分布式锁:
-
创建一个锁目录lock
-
希望获得锁的线程A就在lock目录下,创建临时顺序节点
-
获取锁目录下所有的子节点,然后获取比自己小的兄弟节点,如果不存在,则说明当前线程顺序号最小,获得锁
-
线程B获取所有节点,判断自己不是最小节点,设置监听(watcher)比自己次小的节点(只关注比自己次小的节点是为了防止发生“羊群效应”)
-
线程A处理完,删除自己的节点,线程B监听到变更事件,判断自己是最小的节点,获得锁。