【Java】啃碎JDK源码(八)：ReentrantLock

Z时代
2024-01-10
分类：技术分享

前言

上一次我们已经讲了AQS，如果对其不熟悉的话建议先去看看其实现原理，看完再来看ReentrantLock就很简单了。

啃碎JDK源码(一)：String
啃碎JDK源码(二)：Integer
啃碎JDK源码(三)：ArrayList
啃碎JDK源码(四)：HashMap
啃碎JDK源码(五)：ConcurrentHashMap
啃碎JDK源码(六)：LinkedList
啃碎JDK源码(七)：AbstractQueuedSynchronizer（AQS)

像 ReentrantLock 和 Synchornized 在面试中经常被用来比较，如果想了解Synchronized的话可以看我另外一篇文章:死磕Synchronized

正文

先来了解一下一些核心属性：

public class ReentrantLock implements Lock, java.io.Serializable {
// 实现AQS的内部类
private final Sync sync;
......}

没错，ReentrantLock没有什么值得注意的属性，因为已经在AQS中定义好了，我们只需要继承它然后进行简单的实现即可。

先看下 ReentrantLock 的用法：

  public static void main(String[] args) {
Lock lock = new ReentrantLock();
lock.lock();
try {
// 执行业务
Thread.sleep(1000);
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}}

只要调用 lock 方法就可以进行加锁操作，表示接下来的这段代码已经被当前线程锁住，其他线程需要执行时需要拿到这个锁才能执行，而当前线程在执行完之后要显式的调用 unlock 释放锁。

注意：看源码之前你必须要对AQS比较熟悉才行，可以参考我上一篇博客:
啃碎JDK源码(七)：AbstractQueuedSynchronizer（AQS)

我们来跟进源码看一下，先来看我们的加锁lock方法：

  public void lock() {
sync.lock();
}
// Sync继承了AQS
abstract static class Sync extends AbstractQueuedSynchronizer {
abstract void lock();
......
}

可以看到是调用内部类的lock方法，而它是一个抽象方法，我们看下谁继承了这个抽象接口：

【Java】啃碎JDK源码(八)：ReentrantLock

FairSync 和 NonfairSync 是 ReentrantLock 的另外两个内部类。顾名思义一个是公平锁，一个是非公平锁。（公平锁就是永远都是队列的第一位才能得到锁）

在AQS有一个同步队列(CLH)，是一种先进先出队列。公平锁的意思就是严格按照这个队列的顺序来获取锁，非公平锁的意思就是不一定按照这个队列的顺序来。

在new对象的时候便会对sync初始化，如下：

    public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();}

可以看出默认是非公平锁，如果传true则初始化为公平锁。

那我们首先来看看非公平锁：

  static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
// CAS修改状态
if (compareAndSetState(0, 1))
// 设置独占线程
setExclusiveOwnerThread(Thread.currentThread());
else
// 进入队列等待
acquire(1);
}
// tryAcquire是AQS的抽象方法，我们这里对其实现
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}}

首先用 compareAndSetState 方法使用CAS修改state状态变量的值，如果修改成功的话使用 setExclusiveOwnerThread(Thread.currentThread()) 方法将当前线程设置为独占锁的持有线程，否则调用AQS的 acquire 方法进去队列等待处理。

接下来看一下acquire方法：

   public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();}

该方法是AQS里的方法，我们上次已经介绍过了，这里直接截过来看下：

【Java】啃碎JDK源码(八)：ReentrantLock

这次我们主要关注由子类ReentrantLock实现的tryAcquire方法：

【Java】啃碎JDK源码(八)：ReentrantLock

    protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// 如果锁处于空闲状态
if (c == 0) {
if (compareAndSetState(0, acquires)) {
// 设置当前线程为获取独占锁的线程
setExclusiveOwnerThread(current);
return true;
}
}
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;}

上面代码和我们在上次手动实现一个可重入锁的代码差不多，这里就不再展开。

那接下来看一下 unlock 方法：

   public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
// 尝试释放锁
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;}

release 方法在AQS类中定义好了，我们子类主要实现 tryRelease 方法：

    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;}

这段代码上篇文章我们也已经讲过了，如果忘记的同学可以回头看看。

看完非公平锁的最后来看看公平锁的加锁方法：

     protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
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方法用来判断是否存在比等待更久的线程，因为要按照等待时间顺序获取资源，其它的这里就不再细说了。

其它疑问

以下问题来自从源码角度理解ReentrantLock

为什么基于FIFO的同步队列可以实现非公平锁？

由FIFO队列的特性知，先加入同步队列等待的线程会比后加入的线程更靠近队列的头部，那么它将比后者更早的被唤醒，它也就能更早的得到锁。从这个意义上，对于在同步队列中等待的线程而言，它们获得锁的顺序和加入同步队列的顺序一致，这显然是一种公平模式。然而，线程并非只有在加入队列后才有机会获得锁，哪怕同步队列中已有线程在等待，非公平锁的不公平之处就在于此。回看下非公平锁的加锁流程，线程在进入同步队列等待之前有两次抢占锁的机会:

第一次是使用compareAndSetState方法尝试修改state变量，只有在当前锁未被任何线程占有(包括自身)时才能成功。

第二次是在进入同步队列前使用tryAcquire(arg)尝试获取锁。

只有这两次获取锁都失败后，线程才会构造结点并加入同步队列等待。而线程释放锁时是先释放锁(修改state值)，然后才唤醒后继结点的线程的。试想下这种情况，线程A已经释放锁，但还没来得及唤醒后继线程C，而这时另一个线程B刚好尝试获取锁，此时锁恰好不被任何线程持有，它将成功获取锁而不用加入队列等待。线程C被唤醒尝试获取锁，而此时锁已经被线程B抢占，故而其获取失败并继续在队列中等待。
那我们在开发中为什么大多使用非公平锁？很简单，因为它性能好啊。