从 Java 锁到分布式锁
短信预约 -IT技能 免费直播动态提醒
本文主要是在学习 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 等数据库的锁可以参考实现。
本文转载自微信公众号「程序员小航」,可以通过以下二维码关注。转载本文请联系程序员小航公众号。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341