内容摘要：前言在并发编程中常用到 synchronized 以及 ReentrantLock 锁，在业务开发过程中也可能会用到分布式锁，分布式锁常用框架的就是基于 Redis 实现的分布式锁框架 Redisso

 

前言

在并发编程中常用到 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 等数据库的锁可以参考实现。

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