更多java源码分析请见：jdk11源码分析系列文章专栏：Java11源码分析

@[toc]

概述

ReentrantLock是java中常用的加锁工具，下面是一个典型的写法：

ReentrantLock lock = null;
try {
    System.out.println(System.currentTimeMillis());
    lock = new ReentrantLock();
    lock.lock();
    lock.lock();

    TimeUnit.SECONDS.sleep(1);
    System.out.println(System.currentTimeMillis());
} catch (Exception e) {
    e.printStackTrace();
} finally {
    if (null != lock) {
        lock.unlock();
        lock.unlock();
    }
}

ReentrantLock使用非常灵活，支持公平锁和非公平锁，并且可以与condition配合使用来实现复杂的应用场景。接下来就详细分析一下ReentrantLock的源码实现。

类图
所有源码的解读，都要现有一个概览，从全局解读出发，然后逐步细化理解各个模块的含义。我们先看一下整体的类图：
在这里插入图片描述
其中Sync是ReentrantLock内部的一个抽象类。NonfairSync和FairSync是ReentrantLock公平锁和非公平锁的实现。AbstractQueuedSynchronizer维护了AQS队列，AQS队列是ReentrantLock实现的核心。

new ReentrantLock

ReentrantLock构造函数有两个重载，当参数fair=true时，创建的是公平锁（公平与非公平锁后面会讲）。默认创建的是非公平锁。

public ReentrantLock() {
    sync = new NonfairSync();
}

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();//需注意这里三元运算符的优先级高哦
}

AQS队列

这里简单介绍一下AQS队列的结构，后面会详细介绍队列的变更请求。
AQS的核心实现在AbstractQueuedSynchronizer，该类继承了AbstractOwnableSynchronizer。AbstractOwnableSynchronizer内部实现比较简单，核心代码：

/**
 * 独占模式下，当前锁的拥有者。
 * 指某个线程拥有锁
 */
private transient Thread exclusiveOwnerThread;

protected final void setExclusiveOwnerThread(Thread thread) {
    exclusiveOwnerThread = thread;
}

上面提到了独占模式，AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，ReentrantLock使用该模式）和Share（共享，多个线程可同时执行，Semaphore/CountDownLatch使用该模式）。
在AbstractQueuedSynchronizer的内部类Node中定义了这两种模式：

static final class Node {
    /** 共享模式 */
    static final Node SHARED = new Node();
    /** 独占模式 */
    static final Node EXCLUSIVE = null;
}

好了，进入正题，AQS队列。AQS队列是一个等待队列，他是CLH队列的变体。关键字段如下：

private transient volatile Node head;//队列头 
private transient volatile Node tail; //队列尾
private volatile int state;  //状态

static final class Node {
        static final Node SHARED = new Node();//共享模式
        static final Node EXCLUSIVE = null;  //独占模式

//下面这四个值是变量waitStatus的值
        static final int CANCELLED =  1; 
        static final int SIGNAL    = -1;      
        static final int CONDITION = -2;  
        static final int PROPAGATE = -3;
        
        volatile int waitStatus;
        volatile Node prev;//前驱节点
        volatile Node next;//下一个节点
        volatile Thread thread;//当前节点代表的线程
        /**
        排他锁模式下表示正在等待条件的下一个节点，因为只有排他锁模式有conditions；所以在共享锁模式下，我们使用’SHARED’这个特殊值来表示该字段。
        */
        Node nextWaiter;
}

state是关键之一，他是volatile的，保证了线程间可见性。ReentrantLock加锁的所标记就记录在state中，state初始值是0，每当线程请求一个锁，state加1，在本文开始的代码中，连续获取两个锁，获取锁成功后，state值是2。ReentrantLock是可重入的，之所以可重入，就是依赖这个volatile 的state保证的。当然这里可重入指的是同一个获取锁的线程可以多次获取锁，然后获取N次锁，必须unlock释放N次，保证state=0才表明当前线程释放了锁。
在多线程并发请求锁时，采用CAS修改state的值，修改成功则获取锁成功，修改失败则加入到AQS等待队列尾部。

waitStatus

waitStatus是状态属性，AQS队列的核心之一。他有四个值：

static final int SIGNAL = -1
这个节点的后继节点是阻塞的（LockSupport.park(this)），所以当前节点被释放或者取消时需要唤醒它的后继节点（后继线程）。
static final int CANCELLED = 1;
这个节点由于超时或中断被取消了。CANCELLED 状态的节点永远不会再次阻塞。
static final int CONDITION = -2;
这个节点当前在一个condition队列中。
static final int PROPAGATE = -3;
一个releaseShared操作必须被广播给其他节点。（只有头节点的）该值会在doReleaseShared方法中被设置去确保持续的广播，即便其他操作的介入。
0：不是上面的值的情况。
这个值使用数值排列以简化使用。非负的值表示该节点不需要信号（通知）。因此，大部分代码不需要去检查这个特殊的值，只是为了标识。

对于常规的节点该字段会被初始化为0，竞争节点该值为CONDITION。

AQS队列典型结构图：
在这里插入图片描述

AQS队列的头结点并不关联任何线程，他是一个默认的Node节点。后面enq方法会具体讲

非公平锁加锁

lock.lock();

我们先看非公平锁的实现。由于是非公平锁，所以lock.lock();调用的是NonfairSync类的lock方法：

static final class NonfairSync extends Sync {
        final void lock() {
            if (compareAndSetState(0, 1))      //1
                setExclusiveOwnerThread(Thread.currentThread());  //2
            else
                acquire(1);  //3
        }

        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);   //4
        }
    }

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

总体流程如下：
第一步：CAS原子性的修改AbstractQueuedSynchronizer#state的值，由0改为1，成功则说明当前线程加锁成功.
然后第二步，设置AbstractOwnableSynchronizer#exclusiveOwnerThread的值为当前线程，表示当前锁的拥有者是当前线程。
如果第一步中修改失败，则进入第三步：acquire(1)。申请1个state（共享锁可以申请多个哦），这里可以理解为申请一个信号量，因为ReentrantLock的实现基本都是在java层面使用代码实现的。
acquire方法中首先尝试获取锁tryAcquire（第6步），如果获取失败，则将当前线程以独占模式Node.EXCLUSIVE加入等待队列尾部（addWaiter方法）。
acquireQueued()：以独占无中断模式获取锁，这个方法会一直无限循环，直到获取到资源或者被中断才返回。如果等待过程中被中断则返回true。这里有自旋锁的意思，加入队列中的线程，不断的重试检测是否可以执行任务。

接下来一个一个方法逐个阅读源码：

tryAcquire

tryAcquire的具体实现是在NonfairSync类中，然后调用其父类Sync 中的nonfairTryAcquire（）方法。

static final class NonfairSync extends Sync {
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}
    
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();//:1、获取volatile int state的值
    if (c == 0) {//2：state=0表示当前可以加锁
        if (compareAndSetState(0, acquires)) {//CAS将state设置为acquires的值
            setExclusiveOwnerThread(current);//设置当前拥有锁的线程
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {//当前锁的拥有者线程是currentThread
        int nextc = c + acquires;//将state累加上acquires
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);//设置state的值。由于这里只有获取锁的线程才能执行，所以不会出现并发，不需要额外的加锁处理
        return true;
    }
    return false;//当前锁的拥有者线程不是currentThread，直接返回false，也就是获取锁失败
}

注释已经添加好，nonfairTryAcquire的实现还是比较简单的：如果当前没有锁，那么加锁。如果已经有了锁，那么看看当前锁的拥有者线程是不是currentThread，是则累加state的值，不是则返回失败。
**特别说明：这也是ReentrantLock为什么是可重入锁的原因，同一个线程加多次锁（lock.lock）也就是给state的值累加而已。**

addWaiter和enq方法

按照指定模式（独占还是共享）将节点添加到等待队列。

private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    //1、首先尝试以快速方式添加到队列末尾
    Node pred = tail;//pred指向现有tail末尾节点
    if (pred != null) {
        node.prev = pred;//新加入节点的前一个节点是现有AQS队列的tail节点
        if (compareAndSetTail(pred, node)) {//CAS原子性的修改tail节点
            pred.next = node;//修改成功，新节点成功加入AQS队列，pred节点的next节点指向新的节点
            return node;
        }
    }
    //2、pred为空，或者修改tail节点失败，则走enq方法将节点插入队列
    enq(node);
    return node;
}
private Node enq(final Node node) {
    for(;;) {//CAS
        Node t = tail;
        if (t == null) { // 必须初始化。这里是AQS队列为空的情况。通过CAS的方式创建head节点，并且tail和head都指向同一个节点。
            if (compareAndSetHead(new Node()))//注意这里初始化head节点，并不关联任何线程！！
                tail = head;
        } else {//这里变更node节点的prev指针，并且移动tail指针指向node，前一个节点的next指向新插入的node
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

上面addWaiter方法的第一行代码new Node(Thread.currentThread(), mode);，会创建一个node对象，该对象的重要属性值初始化为：

nextWaiter = Node.EXCLUSIVE; // Node.EXCLUSIVE值为null
thread = Thread.currentThread();
waitStatus = 0;// 默认是0

addWaiter首先会以快速方式将node添加到队尾，如果失败则走enq方法。失败有两种可能，一个是tail为空，也就是AQS为空的情况下。另一是compareAndSetTail失败，也就是多线程并发添加到队尾，此时会出现CAS失败。
注意enq方法，在t==null时，首先创建空的头节点，不关联任何的线程，nextWaiter和thread变量都是null.

AQS队列操作过程中的并发问题

先看一下没有并发的情况，AQS队列的变化过程：

在这里插入图片描述

思考个问题，这里enq方法会存在并发的问题，那么如何保证线程安全的呢？
首先使用CAS来操作线程间的共享变量，比如head,tail。由compareAndSetTail和compareAndSetHead方法保证。

//通过objectFieldOffset方法来获取属性的偏移量，用于后面的CAS操作
headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));
tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
//CAS：比较交换
private final boolean compareAndSetTail(Node expect, Node update) {
    return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
}

其次，prev，next，t这几个变量如何保证线程安全的呢？
enq方法中的tail = head;这行代码，肯定只有一个线程执行，因为上面有一个CAS，这里只有一个线程会修改成功，进入if方法体。而且这里只存在于AQS队列没有初始化时只执行一次，比较简单。
另外，t是方法内部局部变量，是线程私有的，不会有线程安全问题。当多个线程都想添加到AQS队列尾部，肯定只有一个执行compareAndSetTail成功并且移动tail指针指向最新的末尾node，其他线程则会重新执行for循环。

acquireQueued

上面tryAcquire失败没有获取到锁，addWaiter加入了AQS等待队列，进入acquireQueued方法中，acquireQueued方法以独占无中断模式获取锁，这个方法会一直无限循环，直到获取到资源或者被中断才返回。有点类似于自旋锁的意思。

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;//是否获取到资源
    try {
        boolean interrupted = false;//是否中断
        for (;;) {
            final Node p = node.predecessor();//获取前一个节点
            if (p == head && tryAcquire(arg)) {//如果当前node节点是第二个节点，紧跟在head后面，那么tryAcquire尝试获取资源
                setHead(node);//获取锁成功，当前节点成为head节点
                p.next = null; // 目的：辅助GC
                failed = false;
                return interrupted;//返回是否中断过
            }
            
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())//当shouldParkAfterFailedAcquire返回成功，也就是前驱节点是Node.SIGNAL状态时，进行真正的park将当前线程挂起，并且检查中断标记，如果是已经中断，则设置interrupted =true。如果shouldParkAfterFailedAcquire返回false，则重复上述过程，直到获取到资源后者被park。
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);//添加AQS失败，取消任务
    }
}

//前面讲过，head节点不与任何线程关联，他的thread是null，当然head节点的prev肯定也是null
private void setHead(Node node) {
    head = node;
    node.thread = null;
    node.prev = null;
}

//在Acquire失败后，是否要park中断
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws= pred.waitStatus;//获取到上一个节点的waitStatus
    if (ws == Node.SIGNAL)//前面讲到当一个节点状态时SIGNAL时，他有责任唤醒后面的节点。所以这里判断前驱节点是SIGNAL状态，则可以安心的park中断了。
        return true;
    if (ws > 0) {
        /*
         * 过滤掉中间cancel状态的节点
         * 前驱节点被取消的情况（线程允许被取消哦）。向前遍历，知道找到一个waitStatus大于0的（不是取消状态或初始状态）的节点，该节点设置为当前node的前驱节点。
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        /*
         * 修改前驱节点的WaitStatus为Node.SIGNAL。
         * 明确前驱节点必须为Node.SIGNAL，当前节点才可以park 
         * 注意，这个CAS也可能会失败，因为前驱节点的WaitStatus状态可能会发生变化
         */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

//阻塞当前线程
//park并且检查是否被中断过
private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

获取非公平锁过程总结

在这里插入图片描述

cancelAcquire

上面acquireQueued方法在出现异常时，会执行cancelAcquire方法取消当前node的acquire操作。接下来看看cancelAcquire()都做了哪些事情。

private void cancelAcquire(Node node) {
    if (node == null)
        return;

    node.thread = null;

    // 跳过中间CANCELLED状态的节点
    Node pred = node.prev;
    while (pred.waitStatus > 0)
        node.prev = pred = pred.prev;

    Node predNext = pred.next;

    // 将node设置为CANCELLED状态
    node.waitStatus = Node.CANCELLED;

    // 如果当前节点是tail节点，则直接移除
    if (node == tail && compareAndSetTail(node, pred)) {
        compareAndSetNext(pred, predNext, null);
    } else {
        int ws;
        if (pred != head &&
            ((ws = pred.waitStatus) == Node.SIGNAL ||
             (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
            pred.thread != null) {//如果pred不是head节点并且是SIGNAL 状态，或者可以设置为SIGNAL 状态，那么将pred的next设置为node.next，也就是移除当前节点
            Node next = node.next;
            if (next != null && next.waitStatus <= 0)
                compareAndSetNext(pred, predNext, next);
        } else {
            unparkSuccessor(node);//唤醒node的后继节点
        }

        node.next = node; // help GC
    }
}
private void unparkSuccessor(Node node) {
    //如果waitStatus为负数，则将其设置为0（允许失败）
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    //唤醒当前节点后面的节点。通常是紧随的next节点，但是当next被取消或者为空，则从tail到node之间的所有节点，往后往前查找知道找到一个waitStatus <=0的节点，将其唤醒unpark
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

总结一下：
1、设置thread变量为空，并且设置状态为canceled
2、跳过中间的已经被取消的节点
3、如果当前节点是tail节点，则直接移除。否则：
4、如果其前驱节点不是head节点并且（前驱节点是SIGNAL状态，或者可以被设置为SIGNAL状态），那么将当前节点移除。否则通过LockSupport.unpark()唤醒node的后继节点

公平锁加锁

公平锁与非公平锁的区别就在于这里，在tryAcquire方法中，首先会检查是否有任何线程等待获取的时间长于当前线程。
在这里插入图片描述

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

很简单，就是看看AQS队列是否为空，如果不为空，那么head的下一个节点是否为当前请求的线程，如果不是，说明前面有其他线程排队，当前线程应该加入等待队列中。

release

public final boolean release(int arg) {
    if (tryRelease(arg)) {//尝试释放资源  state
        Node h = head;
        if (h != null && h.waitStatus != 0)//如果AQS不为空，并且头节点的waitStatus不是0【重点】
            unparkSuccessor(h);//unpark后继节点
        return true;
    }
    return false;
}

//这里不需要加锁，因为只有获取锁的线程才会来释放锁，所以这里直接将state减去releases即可
protected final boolean tryRelease(int releases) {
    intc = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    //
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)//注意这里是从AQS队列的尾节点开始查找的，找到最后一个 waitStatus<=0 的那个节点，将其唤醒。
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

这里的重点是，彻底释放完资源（state=0）后，会去唤醒AQS队列中的一个等待节点，该节点查找顺序为从AQS队列的尾节点开始查找的，找到最后一个 waitStatus<=0 的那个节点，通过LockSupport.unpark将其唤醒。
这里可能会有疑问，h=head ; h.waitStatus !=0 这个判断合适成立，head初始化时waitStatus=0，waitStatus 是什么时候修改为非0的？其实上面已经列出来了，在shouldParkAfterFailedAcquire中，会有这么一行代码compareAndSetWaitStatus(pred, ws, Node.SIGNAL);，不仅head节点，所有加入AQS队列的节点的前驱节点都会被设置为SIGNAL，因为他们被park后，需要unpark才可以继续执行。
综上，AQS队列是一个FIFO队列。

AQS内部实际状态

这里模拟一种实际加锁的情况，看看AQS队列中实际状态是什么样的。
线程伪代码如下：

new Thread(() -> {
    try {
        lock.lock();
        //do something
    }finally {
        lock.unlock();
    }        
}).start();

假设有4个线程，并发竞争互斥锁。那么队列中有几个节点？state的值是多少？
测试代码如下：

ReentrantLock lock = new ReentrantLock();
newThread(() -> {
    lock.lock();
    try {TimeUnit.SECONDS.sleep(100);} catch (InterruptedException e) {}
    lock.unlock();
}, "aaa").start();
new Thread(() -> {
    lock.lock();
    try {TimeUnit.SECONDS.sleep(100);} catch (InterruptedException e) {}
    lock.unlock();
}, "bbb").start();
new Thread(() -> {
    lock.lock();
    try {TimeUnit.SECONDS.sleep(100);} catch (InterruptedException e) {}
    lock.unlock();
}, "ccc").start();
new Thread(() -> {
    lock.lock();
    try {TimeUnit.SECONDS.sleep(100);} catch (InterruptedException e) {}
    lock.unlock();
}, "ddd").start();

new Thread(() -> {
    for(int i = 0; i < 1000 ; i ++){
        try {
            System.out.println("---> " + lock.getQueueLength() + "  " +  lock.getHoldCount());
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
},"eee").start();

TimeUnit.SECONDS.sleep(50000);//主线程等待

运行代码，打印输出;

---> 3  0
---> 3  0
---> 3  0
---> 3  0

此时看一下线程快照，可以发现，bcd三个线程全部是WAITING状态，而且是由于Unsafe.park导致的WAITING。aaa线程已经进入了TIMED_WAITING状态，由Thread.sleep触发的。
在这里插入图片描述

那么分析一下---> 3 0这个输出结果。
getQueueLength只是简单统计一下AQS队列中的节点数量。源码如下：

public final int getQueueLength() {
    intn = 0;
    for (Node p = tail; p != null; p = p.prev) {//从tail尾结点向前累加
        if (p.thread != null)
            ++n;
    }
    return n;
}

再来看看getHoldCount方法。由于调用getHoldCount方法的线程是eee, 该线程不是加锁的线程，所以会返回0。不过没关系，我们可以加断点，来看一下state的值是多少。

final Thread getOwner() {
    return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
    return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {
    return getState() != 0;
}

在这里插入图片描述
由于我们这里测试的是ReentrantLock，是互斥锁，所以state为1。

加断点看一下所有节点的真实状态，验证上面的逻辑分析。bbb,ccc,ddd三个线程追加在head节点的后面，head节点和ccc,ddd线程的waitstatus=-1，这是因为在添加到AQS队列中时会将其前驱节点设置为NODE.SIGNAL状态。
当然多线程运行时，bbb,ccc,ddd的顺序可能会不同。
在这里插入图片描述
更直观一点：

几个疑问

AQS是FIFO的，那么他是怎么实现非公平锁的？

AQS队列先进先出不假。但是仔细阅读源码，可以发现，在lock时，会首先尝试获取锁。这里就达到了一定的非公平性。思考这种情况：已经存在了AQS队列，且不为空。当获取锁的线程将state全部释放，还没有来得及唤醒后继线程时，此时新加入的线程，则会通过这里的CAS获取到锁，相当于插队了。这也是为什么公平锁的代码中没有这段代码的原因。
在这里插入图片描述
另外，在tryAcquire()方法中，公平和非公平方法获取锁的区别也是在于：非公平锁不去校验AQS中是否有不是当前线程的前驱节点（hasQueuedPredecessors()）。

非公平锁：饥饿

上面也提到了，即使AQS队列中有等待的线程，新来的线程也可能抢先获取到锁。在竞争激烈的情况下，AQS队列中的线程，可能会长时间获取不到锁，影响了正常任务执行，这就是饥饿。

ReentrantLock性能是如何保证的？

首先代码中大量使用了CAS来操作，CAS是无锁的，所以性能比较高。
但是在竞争激烈的情况下，，CAS频繁的进行循环比较，也是非常浪费资源的，比如CPU时钟。因此在jdk代码中，有两处进行了优化：

非公平锁的lock方法中，提前进行一次CAS操作，如果没有这一个其实也是可以的，但是首先进行一次CAS操作，就可以使得一部分线程可以在加入AQS队列前就获取锁，提高了性能。
在入队时，首先尝试直接加入到队列末尾，因为大部分情况下直接加入队尾是OK的。这样避免了enq方法中的其他的复杂逻辑。

ReentrantLock是通过java代码层实现的，那么其线程安全是如何保证的？

整个实现过程中，对于共享变量，通过CAS来实现。其他的变量都在线程内部，是私有变量，不会发生线程安全问题。

羊群效应

简单描述一下羊群效应：假设AQS队列中已经存在了很多等待的线程，那么当获取锁的线程释放锁时，有一种做法是取唤醒所有等待的线程，让他们都去竞争锁，这也符合非公平锁的特征，是比较容易想到的方案。
但是这中方案会造成巨大的资源浪费，首先是需要通知所有的线程去释放锁，然后所有的线程都去竞争锁，虽然ReentrantLock加锁主要是在java层面，但是也是需要耗费大量的CAS操作及CPU时钟，最终只有一个线程抢到锁，其他的还是乖乖回去等待，固不可取。
ReentrantLock给出的解决方案是：维护一个 FIFO 队列，也就是AQS队列，队列中每个节点只关心其前一个节点的状态，线程唤醒也只唤醒队头等待线程。如此一来，即保证了非公平锁的特性，又大大降低了多个线程之间的竞争，提升了性能。

这种方式在《从PAXOS到ZOOKEEPER分布式一致性原理与实践》中的分布式锁一章中也有讲解，请自行查阅。

更多java源码分析请见：jdk11源码分析系列文章专栏：Java11源码分析

jdk11源码-ReentrantLock源码

概述

new ReentrantLock

AQS队列

waitStatus

非公平锁加锁

lock.lock();

tryAcquire

addWaiter和enq方法

AQS队列操作过程中的并发问题

acquireQueued

获取非公平锁过程总结

cancelAcquire

公平锁加锁

release

AQS内部实际状态

几个疑问

AQS是FIFO的，那么他是怎么实现非公平锁的？

非公平锁：饥饿

ReentrantLock性能是如何保证的？

ReentrantLock是通过java代码层实现的，那么其线程安全是如何保证的？

羊群效应

Java技术进阶

热门文章

最新文章

相关课程

相关电子书

相关实验场景

jdk11源码-ReentrantLock源码

概述

new ReentrantLock

AQS队列

waitStatus

非公平锁加锁

lock.lock();

tryAcquire

addWaiter和enq方法

AQS队列操作过程中的并发问题

acquireQueued

获取非公平锁过程总结

cancelAcquire

公平锁加锁

release

AQS内部实际状态

几个疑问

AQS是FIFO的，那么他是怎么实现非公平锁的？

非公平锁：饥饿

ReentrantLock性能是如何保证的？

ReentrantLock是通过java代码层实现的，那么其线程安全是如何保证 的？

羊群效应

Java技术进阶

热门文章

最新文章

相关课程

相关电子书

相关实验场景

ReentrantLock是通过java代码层实现的，那么其线程安全是如何保证的？