从 Java 锁到分布式锁
发布于 2021-11-18 16:57 ,所属分类:软件编程学习资料
前言
在并发编程中常用到 synchronized 以及 ReentrantLock 锁,在业务开发过程中也可能会用到分布式锁,分布式锁常用框架的就是基于 Redis 实现的分布式锁框架 Redisson 和 基于 Zookeeper 实现的分布式锁框架 Curator。当然,也有其他的锁实现方式,在这里不做介绍。
本文主要是在学习 Java 锁以及分布式锁的源码后,做出的归纳总结。
1锁的最基本要素
为什么要使用锁?
关于为什么要使用锁这个问题,答案显而易见:“为了避免多线程并发冲突”。
在多线程中对公共数据的修改,必须要保证只有线程在进行操作。这里的公共数据可以是公共变量,也可以是数据库中的一行数据。
锁的基本要素
知道为什么要加锁之后,就可以得出加锁的基本要素:
锁标志:怎么样才算加锁成功? 锁持有者:是哪个线程加的锁? 锁重入:自己加了锁之后,再次加锁? 锁并发:并发加锁失败的线程该怎么办? 锁释放:用完锁,该怎么释放?
简单来说应该就是这些要素,遗漏之处,欢迎补充。
2加锁标志
加锁标志,就是需要一个标志来表示是否加锁成功,并且这个加锁标志要保证原子性。
synchronized 底层是 C++ 实现的,在 ObjectMonitor 对象中有一个 _count 参数用来标识是否持有锁。 ReentrantLock 基于 AQS 实现,其中 state 表示线程是否持有锁。ReentrantReadWriteLock 同样基于 AQS 实现,其中 state 高 16 位表示读锁,低 16 位表示写锁。 Redisson 是基于 Redis 的 Hash 数据结构实现的,其中加锁 key 是否存在,可以表示是否加锁。 Curator 基于 ZooKeeper 临时顺序节点实现,判断加锁路径下是否存在该节点,来表示是否加锁。
3锁持有者
锁持有者,肯定是当前线程,但是在分布式锁中还需要加上机器,用来防止服务之间的线程冲突。
synchronized 在 ObjectMonitor 对象中 _owner 是指获得锁的线程。 ReentrantLock 和 ReentrantReadWriteLock 是在 AQS 的 Node 节点中有 Thread 对象,用来表示获得锁的线程。 Redisson 在 Hash 数据结构的 field 字段存放的是 UUID:ThreadId,从而保证在多个服务实例时防止并发冲突。 Curator 创建的临时顺序节点包含 UUID,表示加锁机器,结构比如 /locks/lock_01/_c_UUID-lock-0000000000
。
4锁重入
当获得锁的线程再次尝试获取锁的时候,保证需要计数。
synchronized 会对 _count 进行累加,CAS 更新。 ReentrantLock 会对 AQS 的 state 进行累加,CAS 更新。 Redisson 使用 Lua 脚本,对 Hash 结构的 value 进行累加。 Curator 是在 Java 代码中维护了一个 AtomicInteger 类型的 lockCount 字段,用来表示重入。
5锁等待
synchronized 并发加锁失败线程会自旋等待,涉及到偏向锁、轻量级锁、重量级锁的锁升级流程。
刚开始是无锁的 偏向锁:一段同步代码一直被一个线程访问,这个线程自动获取锁,大多数都是由同一个线程获取锁,这就会出现偏向锁。目的是只有一个线程执行同步代码块时提高性能,JDK 6 后在 JVM 中默认开启。对象头标志位(01-无锁) 是否偏向锁标志(1-是偏向锁) 轻量级锁:锁是偏向锁时,被其他线程访问,偏向锁就升级为轻量级锁,其他线程通过自旋形式尝试获取锁 对象头标志位 00 重量级锁:只有一个线程等待,该线程是在自旋等待获取锁。当自旋一定次数或者一个持有锁一个自旋时来了第三个线程,就会升级为重量级锁。对象头标志位 10
ReentrantLock 会放到 AQS 双向同步队列中,监听上一个节点是否为虚拟头结点,是则尝试获取锁。 非公平锁新线程会默认参加抢锁,公平锁会先查看队列是否为空。 自旋等待时会使用 LockSupport.park() 方法,这时候会让出 CPU 资源,其他线程会调用 LockSupport.unpark()。 可以使用 tryLock 方法设置时间,在指定时间内获取锁失败或者被中断,则会返回加锁失败。 Redisson 并发加锁,失败线程会获取到当前锁的超时时间,然后通过 Semaphore tryAcquire 方法阻塞一定时间后,再次尝试获取锁。 公平锁会额外使用 Redis 的 List 数据结构来当做线程等待队列,使用 sorted set 有序集合数据结构来存放等待线程的顺序(score 是超时时间戳)。 Curator 并发加锁会直接创建临时顺序节点,然后监听顺序节点中自己的上一个节点(防止羊群效应),默认是公平锁。
6锁释放
synchronized 不需要手动释放。 ReentrantLock 对 state 递减为 0 后,唤醒后续节点,有后续节点需要调用 LockSupport.unpark(s.thread)。 Redisson 主动释放直接删除 key 即可。超时释放即服务宕机,没有看门狗续租了,指定时间后,Redis Key 就会被自动释放。 Curator 主动释放会删除节点,如果服务宕机了,节点会被自动删除。
7总结
本文从多个角度总结分析了锁和分布式锁的基本要素,同样基于 MySQL 等数据库的锁可以参考实现。
- <End/> -
历史文章 |相关推荐
画图分析 ReentrantLock 源码 图文讲解 AQS 源码 Redisson 分布式锁源码
相关资源