jdk11源码-ReentrantLock源码

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

欢迎关注本人公众号

在这里插入图片描述

概述

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) {
    //新加入节点的前一个节点是现有AQS队列的tail节点
        node.prev = pred;
      	//CAS原子性的修改tail节点
        if (compareAndSetTail(pred, node)) {    
            //修改成功,新节点成功加入AQS队列,pred节点的next节点指向新的节点
            pred.next = node;
            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();

			//如果当前node节点是第二个节点,紧跟在head后面,
			//那么tryAcquire尝试获取资源
            if (p == head && tryAcquire(arg)) {                
                setHead(node);//获取锁成功,当前节点成为head节点
                p.next = null; // 目的:辅助GC
                failed = false;
                return interrupted;//返回是否中断过
            }
            
            //当shouldParkAfterFailedAcquire返回成功,
            //也就是前驱节点是Node.SIGNAL状态时,
            //进行真正的park将当前线程挂起,并且检查中断标记,
            //如果是已经中断,则设置interrupted =true。
            //如果shouldParkAfterFailedAcquire返回false,
            //则重复上述过程,直到获取到资源或者被park。
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                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();
new Thread(() -> {
    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代码中,有两处进行了优化:

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

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

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

羊群效应

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

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

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

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值