概述
在 JDK 1.5 以前, 锁的实现只能用 synchronized 关键字; 1.5 开始提供了 ReentrantLock, 它是 API 层面的锁. 先看下 ReentrantLock 的类签名以及如何使用:
public class ReentrantLock implements Lock, java.io.Serializable {}
典型用法:
- public void m() {
- lock.lock(); // block until condition holds
- try {
- // ... method body
- } finally {
- lock.unlock()
- }
- }
该用法和使用 synchronized 关键字效果是一样的. 既然有了 synchronized, 为什么又会有 Lock 呢? 相比于 synchronized, 其实 ReentrantLock 的出现并不重复, 它增加了不少功能, 下面先简单介绍几个概念.
公平锁 & 非公平锁: 所谓锁是否公平, 简单理解就是一系列线程获取到锁的顺序是否遵循「先来后到」. 即, 如果先申请锁的线程先获取到锁, 就是公平锁; 否则就是非公平锁. ReentrantLock 的默认实现和 synchronized 都是非公平锁.
可重入锁: 锁是否可重入, 就是一个线程是否可以多次获取同一个锁, 若是, 就是可重入锁. ReentrantLock 和 synchronized 都是可重入锁.
代码分析
构造器
ReentrantLock 有两个构造器, 分别如下:
- private final Sync sync;
- // 构造一个 ReentrantLock 实例(非公平锁)
- public ReentrantLock() {
- sync = new NonfairSync();
- }
- // 构造一个 ReentrantLock 实例(指定是否公平)
- public ReentrantLock(boolean fair) {
- sync = fair ? new FairSync() : new NonfairSync();
- }
可以看到, 两个构造器都是初始化一个 Sync 类型的成员变量. 而且, 当 boolean 值 fair 为 true 时, 初始化的 sync 为 FairSync, 为 false 时初始化为 NonFairSync, 二者分别表示「公平锁」和「非公平锁」. 可以看到无参构造默认是非公平锁.
常用方法
ReentrantLock 常用的方法就是 Lock 接口定义的几个方法, 如下:
- // 获取锁(阻塞式)
- public void lock() {
- sync.lock();
- }
- // 获取锁(响应中断)
- public void lockInterruptibly() throws InterruptedException {
- sync.acquireInterruptibly(1);
- }
- // 尝试获取锁
- public boolean tryLock() {
- return sync.nonfairTryAcquire(1);
- }
- // 尝试获取锁(有超时等待)
- public boolean tryLock(long timeout, TimeUnit unit)
- throws InterruptedException {
- return sync.tryAcquireNanos(1, unit.toNanos(timeout));
- }
- // 释放锁
- public void unlock() {
- sync.release(1);
- }
可以看到, 这几个方法内部都是通过调用 Sync 类 (或其子类) 的方法来实现, 因此先从 Sync 类入手分析, 代码如下(部分省略):
- // 抽象类, 继承了 AQS
- abstract static class Sync extends AbstractQueuedSynchronizer {
- // 获取锁的方法, 由子类实现
- abstract void lock();
- // 非公平锁的 tryLock 方法实现
- final boolean nonfairTryAcquire(int acquires) {
- final Thread current = Thread.currentThread();
- // 获取 AQS 的 state 变量
- int c = getState();
- // 若为 0, 表示当前没有被其他线程占用
- if (c == 0) {
- // CAS 修改 state, 若修改成功, 表示成功获取资源
- if (compareAndSetState(0, acquires)) {
- // 将当前线程设置为 owner, 到这里表示当前线程成功获取资源
- setExclusiveOwnerThread(current);
- return true;
- }
- }
- // state 不为 0, 且 owner 为当前线程
- // 表示当前线程已经获取到了资源, 这里表示 "重入"
- else if (current == getExclusiveOwnerThread()) {
- int nextc = c + acquires;
- if (nextc < 0) // overflow
- throw new Error("Maximum lock count exceeded");
- // 修改 state 值(因为当前线程已经获取资源, 不存在竞争, 因此无需 CAS 操作)
- setState(nextc);
- return true;
- }
- return false;
- }
- // 释放锁操作(对 state 做减法)
- protected final boolean tryRelease(int releases) {
- int c = getState() - releases;
- if (Thread.currentThread() != getExclusiveOwnerThread())
- throw new IllegalMonitorStateException();
- boolean free = false;
- if (c == 0) {
- free = true;
- // 成功释放后将 owner 设为空
- setExclusiveOwnerThread(null);
- }
- // 修改 state 的值
- // PS: 因为可能存在 "重入", 因此一次释放操作后当前线程仍有可能占用资源,
- // 所以不会直接把 state 设为 0
- setState(c);
- return free;
- }
- // 其他方法...
- final boolean isLocked() {
- return getState() != 0;
- }
- }
Sync 类继承自 AQS, 其中 nonfairTryAcquire 方法是非公平锁 tryAcquire 方法的实现.
从上面代码可以看出, 锁的获取和释放是通过修改 AQS 的 state 变量来实现的. lock 方法可以看做对 state 执行 "加法" 操作, 而 unlock 可以看做对 state 执行 "减法" 操作, 当 state 为 0 时, 表示当前没有线程占用资源.
公平锁 & 非公平锁
(1)非公平锁 NonFairSync:
- static final class NonfairSync extends Sync {
- final void lock() {
- // CAS 尝试将 state 值修改为 1
- if (compareAndSetState(0, 1))
- // 若修改成功, 则将当前线程设为 owner, 表示成功获取锁
- setExclusiveOwnerThread(Thread.currentThread());
- // 若获取失败, 则执行 AQS 的 acquire 方法(独占模式获取资源)
- else
- acquire(1);
- }
- protected final boolean tryAcquire(int acquires) {
- return nonfairTryAcquire(acquires);
- }
- }
可以看到, 非公平锁的 lock 操作为: 先尝试以 CAS 方式修改 state 的值, 若修改成功, 则表示成功获取到锁, 将 owner 设为当前线程; 否则就执行 AQS 中的 acquire 方法, 具体可参考前文「JDK 源码分析 - AbstractQueuedSynchronizer(2)」, 这里不再赘述.
(2)公平锁 FairSync:
- static final class FairSync extends Sync {
- final void lock() {
- acquire(1);
- }
- // 公平锁的 tryAcquire 实现
- protected final boolean tryAcquire(int acquires) {
- final Thread current = Thread.currentThread();
- int c = getState();
- // state 为 0, 表示资源未被占用
- if (c == 0) {
- // 若队列中有其他线程在排队等待, 则返回 false, 表示获取失败;
- // 否则, 再尝试去修改 state 的值
- // PS: 这里是公平锁与非公平锁的区别所在
- if (!hasQueuedPredecessors() &&
- compareAndSetState(0, acquires)) {
- setExclusiveOwnerThread(current);
- return true;
- }
- }
- // 若当前线程已占用了锁, 则 "重入"
- else if (current == getExclusiveOwnerThread()) {
- int nextc = c + acquires;
- if (nextc < 0)
- throw new Error("Maximum lock count exceeded");
- setState(nextc);
- return true;
- }
- return false;
- }
- }
可以看到, 与非公平锁相比, 公平锁的不同之处在于增加了判断条件 hasQueuedPredecessors, 即首先判断主队列中是否有其他线程在等待, 当没有其他线程在排队时再去获取, 否则获取失败.
hasQueuedPredecessors 在 AQS 中实现如下:
- /**
- * Queries whether any threads have been waiting to acquire longer
- * than the current thread.
- */
- public final boolean hasQueuedPredecessors() {
- // The correctness of this depends on head being initialized
- // before tail and on head.next being accurate if the current
- // thread is first in queue.
- Node t = tail; // Read fields in reverse initialization order
- Node h = head;
- Node s;
- return h != t &&
- ((s = h.next) == null || s.thread != Thread.currentThread());
- }
小结
synchronized 与 ReentrantLock 比较:
相同点: 二者都是互斥锁, 可重入, 默认都是非公平锁.
不同点: synchronized 是语法层面实现, 自动获取锁和释放锁; ReentrantLock 是 API 层面实现, 手动获取锁和释放锁.
ReentrantLock 相比 synchronized 的优势:
1. 可响应中断;
2. 获取锁可设置超时;
3. 可实现公平锁;
4. 可绑定多个条件(Condition).
JDK 1.6 以后, synchronized 与 ReentrantLock 性能基本持平, JVM 未来的性能优化也会更偏向于原生的 synchronized. 因此, 如何选择还要根据实际需求, 性能不再是不选择 synchronized 的原因了.
来源: https://www.cnblogs.com/jaxer/p/11311997.html