前言

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

本文主要是在学习 Java 锁以及分布式锁的源码后,做出的归纳总结。

锁的最基本要素

为什么要使用锁?

关于为什么要使用锁这个问题,答案显而易见:“为了避免多线程并发冲突”。

在多线程中对公共数据的修改,必须要保证只有线程在进行操作。这里的公共数据可以是公共变量,也可以是数据库中的一行数据。

锁的基本要素

知道为什么要加锁之后,就可以得出加锁的基本要素:

  1. 锁标志:怎么样才算加锁成功?
  2. 锁持有者:是哪个线程加的锁?
  3. 锁重入:自己加了锁之后,再次加锁?
  4. 锁并发:并发加锁失败的线程该怎么办?
  5. 锁释放:用完锁,该怎么释放?

简单来说应该就是这些要素,遗漏之处,欢迎补充。

加锁标志

加锁标志,就是需要一个标志来表示是否加锁成功,并且这个加锁标志要保证原子性。

  • synchronized 底层是 C++ 实现的,在 ObjectMonitor 对象中有一个 _count 参数用来标识是否持有锁。
  • ReentrantLock 基于 AQS 实现,其中 state 表示线程是否持有锁。ReentrantReadWriteLock 同样基于 AQS 实现,其中 state 高 16 位表示读锁,低 16 位表示写锁。
  • Redisson 是基于 Redis 的 Hash 数据结构实现的,其中加锁 key 是否存在,可以表示是否加锁。
  • Curator 基于 ZooKeeper 临时顺序节点实现,判断加锁路径下是否存在该节点,来表示是否加锁。

锁持有者

锁持有者,肯定是当前线程,但是在分布式锁中还需要加上机器,用来防止服务之间的线程冲突。

  • synchronized 在 ObjectMonitor 对象中 _owner 是指获得锁的线程。
  • ReentrantLock 和 ReentrantReadWriteLock 是在 AQS 的 Node 节点中有 Thread 对象,用来表示获得锁的线程。
  • Redisson 在 Hash 数据结构的 field 字段存放的是 UUID:ThreadId,从而保证在多个服务实例时防止并发冲突。
  • Curator 创建的临时顺序节点包含 UUID,表示加锁机器,结构比如 /locks/lock_01/_c_UUID-lock-0000000000

锁重入

当获得锁的线程再次尝试获取锁的时候,保证需要计数。

  • synchronized 会对 _count 进行累加,CAS 更新。
  • ReentrantLock 会对 AQS 的 state 进行累加,CAS 更新。
  • Redisson 使用 Lua 脚本,对 Hash 结构的 value 进行累加。
  • Curator 是在 Java 代码中维护了一个 AtomicInteger 类型的 lockCount 字段,用来表示重入。

锁等待

  • 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 并发加锁会直接创建临时顺序节点,然后监听顺序节点中自己的上一个节点(防止羊群效应),默认是公平锁。

锁释放

  • synchronized 不需要手动释放。
  • ReentrantLock 对 state 递减为 0 后,唤醒后续节点,有后续节点需要调用 LockSupport.unpark(s.thread)。
  • Redisson 主动释放直接删除 key 即可。超时释放即服务宕机,没有看门狗续租了,指定时间后,Redis Key 就会被自动释放。
  • Curator 主动释放会删除节点,如果服务宕机了,节点会被自动删除。

总结

本文从多个角度总结分析了锁和分布式锁的基本要素,同样基于 MySQL 等数据库的锁可以参考实现。

相关阅读

上一篇 下一篇