在阅读完 JUC 包下的 AQS 源码之后,其中有很多疑问,最大的疑问就是 state 究竟是什么含义?并且 AQS 主要定义了队列的出入,但是获取资源、释放资源都是交给子类实现的,那子类是怎么实现的呢?下面开始了解 ReentrantLock。

介绍

一个可重入的互斥锁与隐式监视器锁synchronized具有相同的基本行为和语义,但功能更强大。
具有以下特征:

  1. 互斥性:同时只有一个线程可以获取到该锁,此时其他线程请求获取锁,会被阻塞,然后被放到该锁内部维护的一个 AQS 阻塞队列中。
  2. 可重入性:维护 state 变量,初始为 0,当一个线程获取到锁时,state 使用 cas 更新为 1,本线程再次申请获取锁,会对 state 进行 CAS 递增,重复获取次数即 state,最多为 2147483647 。试图超出此限制会从锁定方法抛出 Error。
  3. 公平/非公平性:在初始化时,可以通过构造器传参,指定是否为公平锁,还是非公平锁。当设置为 true 时,为公平锁,线程争用锁时,会倾向于等待时间最长的线程。

    基本使用

    1. class X {
    2. private final ReentrantLock lock = new ReentrantLock();
    3. // ...
    4. public void m() {
    5. lock.lock(); // block until condition holds
    6. try {
    7. // ... method body
    8. } finally {
    9. lock.unlock()
    10. }
    11. }
    12. }

    问题疑问?

    首先在阅读本文时,对 AQS 有了一定的了解,如果不了解的话,可以看以下之前的文章。图文讲解 AQS

  4. 在 AQS 中介绍 state 时,说 state 含义由子类进行定义,那在 ReentrantLock 中 state 代表什么?

  5. ReentrantLock 和 AQS 有什么关系?
  6. 线程是如何获取到锁的?
  7. 锁的可重入性是如何实现的?
  8. 当前线程获取锁失败,被阻塞的后续操作是什么?
  9. 公平锁和非公平锁是如何体现的?
  10. 锁是如何释放的?

将通过源码及画图的方式,围绕上面几个问题,展开阅读和分析。

源码分析

基本结构

ReentrantLock - 图1
基本结构如图所示,ReentrantLock 类实现了接口 Lock,在接口 Lock 中定义了使用锁时的方法,方法及含义如下:

  1. public interface Lock {
  2. // 获取锁,如果没有获取到,会阻塞。
  3. void lock();
  4. // 获取锁,如果没有获取到,会阻塞。响应中断。
  5. void lockInterruptibly() throws InterruptedException;
  6. // 尝试获取锁,如果获取到,返回 true,没有获取到 返回 false
  7. boolean tryLock();
  8. // 尝试获取锁,没有有获取到,会等待指定时间,响应中断。
  9. boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
  10. // 释放锁
  11. void unlock();
  12. }

而 ReentrantLock 也只是实现了 Lock 接口,并实现了这些方法,那 ReentrantLock 和 AQS 到底有什么关系呢?这就需要看内部具体如何实现的了。
通过上面类图可以看出,在 ReentrantLock 中含有两个内部类,分别是 NonfairSync FairSync 而它俩又实现了 抽象类 Sync,抽象类 Sync 继承了 AbstractQueuedSynchronizer 即 AQS。具体代码如下:

  1. public class ReentrantLock implements Lock, java.io.Serializable {
  2. private final Sync sync;
  3. // 锁的同步控制基础类。 子类具体到公平和非公平的版本。 使用AQS状态来表示持有该锁的数量。
  4. abstract static class Sync extends AbstractQueuedSynchronizer {
  5. // 省略 ...
  6. }
  7. static final class NonfairSync extends Sync {
  8. // 非公平锁逻辑 省略 ...
  9. }
  10. static final class FairSync extends Sync {
  11. // 公平锁逻辑 省略 ...
  12. }
  13. // 默认非公平锁
  14. public ReentrantLock() {
  15. sync = new NonfairSync();
  16. }
  17. // 根据传参指定公平锁还是非公平锁,true 公平锁,false 非公平锁
  18. public ReentrantLock(boolean fair) {
  19. sync = fair ? new FairSync() : new NonfairSync();
  20. }
  21. }

通过上面代码可以看出:

  1. 锁的基本控制是由 NonfairSync 和 FairSync 进行控制的,而它俩的父类 Sync 继承了 AQS (AbstractQueuedSynchronizer),这也就是说明 ReentrantLock 的实现和 AQS 是有关的。
  2. NonfairSync 代表非公平锁实现逻辑,FairSync 代表公平锁实现逻辑。
  3. 构造器传参可以看出,初始化时,默认为 NonfairSync 非公平锁。也可以指定声明为公平锁或非公平锁,传参 true 为 公平锁,false 为非公平锁。

具体 ReentrantLock 和 AQS 的关系是怎样的,就需要通过加锁的过程来分析了。
ReentrantLock - 图2

lock

ReentrantLock - 图3
如图所示,默认声明非公平锁,lock 方法内部调用 sync.lock(); 此时应该是使用的非公平锁内部的 lock 加锁操作。

  1. final void lock() {
  2. // 通过 CAS 设置 state 值 0 -> 1
  3. if (compareAndSetState(0, 1))
  4. // 设置成功当前线程获取到了锁
  5. setExclusiveOwnerThread(Thread.currentThread());
  6. else
  7. // 设置失败,则调用 AQS 的方法,尝试获取锁。
  8. acquire(1);
  9. }
  1. 首先会 使用 CAS 更新 state 的值, 此时就会发现, state 在这里代表的锁的状态。 0 未加锁,1 加锁。
  2. 设置失败,会调用 AQS 的 acquire(1); 方法。

再看下 AQS 的 acquire 代码

  1. public final void acquire(int arg) {
  2. // tryAcquire 尝试获取 state,获取失败则会加入到队列
  3. if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  4. selfInterrupt();
  5. }

在之前分析 AQS 源码时,已经介绍 tryAcquire 是尝试获取 state 的值,AQS 中并不提供可用的方法,此处是由子类实现的。所以这块代码还是在 NonfairSync 类中自己实现的业务逻辑。

  1. static final class NonfairSync extends Sync {
  2. // NonfairSync 实现
  3. protected final boolean tryAcquire(int acquires) {
  4. // 调用父类的方法
  5. return nonfairTryAcquire(acquires);
  6. }
  7. }
  8. abstract static class Sync extends AbstractQueuedSynchronizer {
  9. // NonfairSync 的父类 Sync 中有实现
  10. // state 传参是 1
  11. final boolean nonfairTryAcquire(int acquires) {
  12. // 获取当前线程
  13. final Thread current = Thread.currentThread();
  14. // 获取 state
  15. int c = getState();
  16. // 如果 c 是 0
  17. if (c == 0) {
  18. // 使用 cas 更新为 1
  19. if (compareAndSetState(0, acquires)) {
  20. // 设置持有线程为当前
  21. setExclusiveOwnerThread(current);
  22. return true;
  23. }
  24. } else if (current == getExclusiveOwnerThread()) {
  25. // 如果是当前线程持有
  26. // 对 state 进行累加
  27. int nextc = c + acquires;
  28. // 不允许超过 int 的最大值 2147483647 + 1 = -2147483648
  29. if (nextc < 0) // overflow
  30. throw new Error("Maximum lock count exceeded");
  31. // 设置 state 的值
  32. setState(nextc);
  33. return true;
  34. }
  35. return false;
  36. }
  37. }
  1. 当前线程加锁,直接使用 CAS 方式对 state 从 0 更新为 1,更新成功,则获得锁,更新失败,则获取失败。
  2. 更新失败后会调用 AQS 的 acquire(1); 方法, 此处传参为 1。
  3. tryAcquire 再次尝试获取锁。
    1. state 是 0,尝试获取。获取成功返回 true;
    2. state 不是 0,判断是否为当前线程持有,是当前线程持有则对 state 进行累加。
  4. tryAcquire 获取锁失败,则走 AQS 的 acquireQueued 逻辑,创建节点,并加入到等待队列中。

流程画图如下:

  • 初始为单个线程

ReentrantLock - 图4

  • 此时其他线程来请求获取锁

ReentrantLock - 图5

  • 加锁流程图

ReentrantLock - 图6

再来看下公平锁是如何体现的?

  1. static final class FairSync extends Sync {
  2. private static final long serialVersionUID = -3000897897090466540L;
  3. final void lock() {
  4. acquire(1);
  5. }
  6. protected final boolean tryAcquire(int acquires) {
  7. final Thread current = Thread.currentThread();
  8. int c = getState();
  9. if (c == 0) {
  10. // 判断有无节点排队
  11. if (!hasQueuedPredecessors() &&
  12. compareAndSetState(0, acquires)) {
  13. setExclusiveOwnerThread(current);
  14. return true;
  15. }
  16. }
  17. else if (current == getExclusiveOwnerThread()) {
  18. int nextc = c + acquires;
  19. if (nextc < 0)
  20. throw new Error("Maximum lock count exceeded");
  21. setState(nextc);
  22. return true;
  23. }
  24. return false;
  25. }
  26. }

拉出来代码比较一下:
ReentrantLock - 图7
可以看出在公平锁(FairSync)中多了一个判断条件
**!hasQueuedPredecessors()**
hasQueuedPredecessors 方法在 AQS 中,如果有当前线程前面的线程排队返回true,如果当前线程是在队列的头部或队列为空,返回false。
代码如下:

public final boolean hasQueuedPredecessors() {
    Node t = tail; 
    Node h = head;
    Node s;
    return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());
}

如果当前加锁时已经有节点在排队,那就去节点尾部排队,否则才会去抢占锁。
到这里基本上已经知道公平锁和非公平锁的区别了:
非公平锁:不管有没有节点在排队,都会试图去获取锁,如果获取失败,进入 acquire 方法,还是会试图获取一次,之后才会进入队列中。
公平锁:已经有节点在排队,那就自己去节点后面排队。

tryLock

public boolean tryLock() {
    return sync.nonfairTryAcquire(1);
}

直接调用的 Sync 中的 nonfairTryAcquire, 尝试获取锁,获取失败,就返回 false,获取到锁或者是当前线程持有锁则对 state 累加后都返回 true。

unlock

public void unlock() {
    sync.release(1);
}

发现 unlock 直接调用的 AQS 的 release 方法,进行释放资源。

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

这块在 AQS 中有介绍,也说明 tryRelease 由子类进行实现,现在在 ReentrantLock 重点关注 tryRelease 的实现。

// 释放资源,传入值为 1
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;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}
  1. 获取当前的 state 进行 -1 操作;
  2. 判断了下当前线程是否为持有线程;
  3. 如果释放完之后 state 为 0 ,则设置持有线程为 null;
  4. 更新并返回 state 的值。

    总结

    通过上面的源码及画图,基本上对开始的问题已经有了答案:
    Q:在 AQS 中介绍 state 时,说 state 含义由子类进行定义,那在 ReentrantLock 中 state 代表什么?
    A:在 ReentrantLock 中 state 代表加锁状态,0 没有线程获得锁,大于等于 1 已经有线程获得锁,大于 1 说明该获得锁的线程多次重入。
    Q:ReentrantLock 和 AQS 有什么关系?
    A:ReentrantLock 内部基于 AQS 实现,无论是锁状态,还是进入等待队列,锁释放等都是基于 AQS 实现。ReentrantLock 的公平锁和非公平锁都是 NonfairSync、FairSync 来实现的,而他们的父类 Sync 继承了 AQS。
    Q:线程是如何获取到锁的?
    A:线程通过修改 state 字段的状态来获取到锁。
    Q:锁的可重入性是如何实现的?
    A:当前线程发现 state 不是 0 ,则说明有锁已经被获取了,此时会判断当前获取到锁的线程是不是自己,如果是,则对 state 进行累加。
    Q:当前线程获取锁失败,被阻塞的后续操作是什么?
    A:获取失败,会放到 AQS 等待队列中,在队列中不断循环,监视前一个节点是否为 head ,是的话,会重新尝试获取锁。
    Q:公平锁和非公平锁是如何体现的?
    A:公平锁主要体现在如果当前队列中已经有排队的线程了,则自己直接排在后面。非公平锁是不管当前队列都没有线程排队,都会直接尝试修改 state 获取锁。
    Q:锁是如何释放的?
    A:锁释放资源,即将 state 进行 -1 操作,如果 -1 后 state 为 0,则释放节点,后续节点尝试获取锁。此处可以看 AQS 相关逻辑。