从 Java 锁到分布式锁

作者：程序员小航 2021-11-26 06:43:19

开发

后端

分布式 在并发编程中常用到 synchronized 以及 ReentrantLock 锁，在业务开发过程中也可能会用到分布式锁，分布式锁常用框架的就是基于 Redis 实现的分布式锁框架 Redisson 和 基于 Zookeeper 实现的分布式锁框架 Curator。当然，也有其他的锁实现方式，在这里不做介绍。

 [[436819]]

前言

在并发编程中常用到 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 并发加锁失败线程会自旋等待，涉及到偏向锁、轻量级锁、重量级锁的锁升级流程。

1. 刚开始是无锁的
2. 偏向锁：一段同步代码一直被一个线程访问，这个线程自动获取锁，大多数都是由同一个线程获取锁，这就会出现偏向锁。目的是只有一个线程执行同步代码块时提高性能，JDK 6 后在 JVM 中默认开启。对象头标志位(01-无锁) 是否偏向锁标志(1-是偏向锁)
3. 轻量级锁：锁是偏向锁时，被其他线程访问，偏向锁就升级为轻量级锁，其他线程通过自旋形式尝试获取锁 对象头标志位 00
4. 重量级锁：只有一个线程等待，该线程是在自旋等待获取锁。当自旋一定次数或者一个持有锁一个自旋时来了第三个线程，就会升级为重量级锁。对象头标志位 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 等数据库的锁可以参考实现。

 本文转载自微信公众号「程序员小航」，可以通过以下二维码关注。转载本文请联系程序员小航公众号。