【深刻AQS原理】我画了35张图就是为了让你深刻 AQS

时间  2021-08-13
标签 html java node 安全 markdown 数据结构 多线程 并发 post 性能 栏目 HTML 繁體版
原文   原文链接

申明

此文章肝了好久，图片较多，但愿你们喜欢。html

另外，感兴趣的小伙伴可关注我的公众号：一枝花算不算浪漫java

公众号刚开始运营，但愿与您一同成长。node

前言

谈到并发，咱们不得不说AQS(AbstractQueuedSynchronizer)，所谓的AQS便是抽象的队列式的同步器，内部定义了不少锁相关的方法，咱们熟知的ReentrantLock、ReentrantReadWriteLock、CountDownLatch、Semaphore等都是基于AQS来实现的。安全

咱们先看下AQS相关的UML图：markdown

image.png

思惟导图：数据结构

image.png

AQS实现原理

AQS中 维护了一个volatile int state（表明共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。多线程

这里volatile可以保证多线程下的可见性，当state=1则表明当前对象锁已经被占有，其余线程来加锁时则会失败，加锁失败的线程会被放入一个FIFO的等待队列中，比列会被UNSAFE.park()操做挂起，等待其余获取锁的线程释放锁才可以被唤醒。并发

另外state的操做都是经过CAS来保证其并发修改的安全性。post

具体原理咱们能够用一张图来简单归纳：性能

image.png

AQS 中提供了不少关于锁的实现方法，

  • getState()：获取锁的标志state值
  • setState()：设置锁的标志state值
  • tryAcquire(int)：独占方式获取锁。尝试获取资源，成功则返回true，失败则返回false。
  • tryRelease(int)：独占方式释放锁。尝试释放资源，成功则返回true，失败则返回false。

这里还有一些方法并无列出来，接下来咱们以ReentrantLock做为突破点经过源码和画图的形式一步步了解AQS内部实现原理。

目录结构

文章准备模拟多线程竞争锁、释放锁的场景来进行分析AQS源码：

三个线程(线程1、线程2、线程三)同时来加锁/释放锁

目录以下：

  • 线程一加锁成功时AQS内部实现
  • 线程二/三加锁失败时AQS中等待队列的数据模型
  • 线程一释放锁及线程二获取锁实现原理
  • 经过线程场景来说解公平锁具体实现原理
  • 经过线程场景来说解Condition中await()和signal()实现原理

这里会经过画图来分析每一个线程加锁、释放锁后AQS内部的数据结构和实现原理

场景分析

线程一加锁成功

若是同时有三个线程并发抢占锁，此时线程一抢占锁成功，线程二和线程三抢占锁失败，具体执行流程以下：

image.png

此时AQS内部数据为：

image.png

线程二、线程三加锁失败：

image.png

有图能够看出，等待队列中的节点Node是一个双向链表，这里SIGNAL是Node中waitStatus属性，Node中还有一个nextWaiter属性，这个并未在图中画出来，这个到后面Condition会具体讲解的。

具体看下抢占锁代码实现：

java.util.concurrent.locks.ReentrantLock .NonfairSync:

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

    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}
复制代码

这里使用的ReentrantLock非公平锁，线程进来直接利用CAS尝试抢占锁，若是抢占成功state值回被改成1，且设置对象独占锁线程为当前线程。以下所示：

protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

protected final void setExclusiveOwnerThread(Thread thread) {
    exclusiveOwnerThread = thread;
}
复制代码

线程二抢占锁失败

咱们按照真实场景来分析，线程一抢占锁成功后，state变为1，线程二经过CAS修改state变量必然会失败。此时AQS中FIFO(First In First Out 先进先出)队列中数据如图所示：

image.png

咱们将线程二执行的逻辑一步步拆解来看：

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire():

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

先看看tryAcquire()的具体实现： java.util.concurrent.locks.ReentrantLock .nonfairTryAcquire():

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)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}
复制代码

nonfairTryAcquire()方法中首先会获取state的值，若是不为0则说明当前对象的锁已经被其余线程所占有，接着判断占有锁的线程是否为当前线程，若是是则累加state值，这就是可重入锁的具体实现，累加state值，释放锁的时候也要依次递减state值。

若是state为0，则执行CAS操做，尝试更新state值为1，若是更新成功则表明当前线程加锁成功。

以线程二为例，由于线程一已经将state修改成1，因此线程二经过CAS修改state的值不会成功。加锁失败。

线程二执行tryAcquire()后会返回false，接着执行addWaiter(Node.EXCLUSIVE)逻辑，将本身加入到一个FIFO等待队列中，代码实现以下：

java.util.concurrent.locks.AbstractQueuedSynchronizer.addWaiter():

private Node addWaiter(Node mode) {    
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}
复制代码

这段代码首先会建立一个和当前线程绑定的Node节点，Node为双向链表。此时等待对内中的tail指针为空，直接调用enq(node)方法将当前线程加入等待队列尾部：

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) {
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}
复制代码

第一遍循环时tail指针为空，进入if逻辑，使用CAS操做设置head指针，将head指向一个新建立的Node节点。此时AQS中数据：

image.png

执行完成以后，head、tail、t都指向第一个Node元素。

接着执行第二遍循环，进入else逻辑，此时已经有了head节点，这里要操做的就是将线程二对应的Node节点挂到head节点后面。此时队列中就有了两个Node节点：

image.png

addWaiter()方法执行完后，会返回当前线程建立的节点信息。继续日后执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg) 逻辑，此时传入的参数为线程二对应的Node节点信息：

java.util.concurrent.locks.AbstractQueuedSynchronizer.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)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndChecknIterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        return true;
    if (ws > 0) {
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}
复制代码

acquireQueued()这个方法会先判断当前传入的Node对应的前置节点是否为head，若是是则尝试加锁。加锁成功过则将当前节点设置为head节点，而后空置以前的head节点，方便后续被垃圾回收掉。

若是加锁失败或者Node的前置节点不是head节点，就会经过shouldParkAfterFailedAcquire方法 将head节点的waitStatus变为了SIGNAL=-1，最后执行parkAndChecknIterrupt方法，调用LockSupport.park()挂起当前线程。

此时AQS中的数据以下图：

image.png

此时线程二就静静的待在AQS的等待队列里面了，等着其余线程释放锁来唤醒它。

线程三抢占锁失败

看完了线程二抢占锁失败的分析，那么再来分析线程三抢占锁失败就很简单了，先看看addWaiter(Node mode)方法：

private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}
复制代码

此时等待队列的tail节点指向线程二，进入if逻辑后，经过CAS指令将tail节点从新指向线程三。接着线程三调用enq()方法执行入队操做，和上面线程二执行方式是一致的，入队后会修改线程二对应的Node中的waitStatus=SIGNAL。最后线程三也会被挂起。此时等待队列的数据如图：

image.png

线程一释放锁

如今来分析下释放锁的过程，首先是线程一释放锁，释放锁后会唤醒head节点的后置节点，也就是咱们如今的线程二，具体操做流程以下：

image.png

执行完后等待队列数据以下：

image.png

此时线程二已经被唤醒，继续尝试获取锁，若是获取锁失败，则会继续被挂起。若是获取锁成功，则AQS中数据如图：

image.png

接着仍是一步步拆解来看，先看看线程一释放锁的代码：

java.util.concurrent.locks.AbstractQueuedSynchronizer.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;
}
复制代码

这里首先会执行tryRelease()方法，这个方法具体实如今ReentrantLock中，若是tryRelease执行成功，则继续判断head节点的waitStatus是否为0，前面咱们已经看到过，head的waitStatue为SIGNAL(-1)，这里就会执行unparkSuccessor()方法来唤醒head的后置节点，也就是咱们上面图中线程二对应的Node节点。

此时看ReentrantLock.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;
}
复制代码

执行完ReentrantLock.tryRelease()后，state被设置成0，Lock对象的独占锁被设置为null。此时看下AQS中的数据：

image.png

接着执行java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor()方法，唤醒head的后置节点：

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)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}
复制代码

这里主要是将head节点的waitStatus设置为0。

此时从新将head指针指向线程二对应的Node节点，且使用LockSupport.unpark方法来唤醒线程二。

被唤醒的线程二会接着尝试获取锁，用CAS指令修改state数据。 执行完成后能够查看AQS中数据：

image.png

此时线程二被唤醒，线程二接着以前被park的地方继续执行，继续执行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)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}
复制代码

此时线程二被唤醒，继续执行for循环，判断线程二的前置节点是否为head，若是是则继续使用tryAcquire()方法来尝试获取锁，其实就是使用CAS操做来修改state值，若是修改为功则表明获取锁成功。接着将线程二设置为head节点，而后空置以前的head节点数据，被空置的节点数据等着被垃圾回收。

此时线程二获取锁成功，AQS中队列数据以下：

image.png

等待队列中的数据都等待着被垃圾回收。

线程二释放锁/线程三加锁

当线程二释放锁时，会唤醒被挂起的线程三，流程和上面大体相同，被唤醒的线程三会再次尝试加锁，具体代码能够参考上面内容。具体流程图以下：

image.png

此时AQS中队列数据如图：

image.png

公平锁实现原理

上面全部的加锁场景都是基于非公平锁来实现的，非公平锁是ReentrantLock的默认实现，那咱们接着来看一下公平锁的实现原理，这里先用一张图来解释公平锁和非公平锁的区别：

非公平锁执行流程：

image.png

这里咱们仍是用以前的线程模型来举例子，当线程二释放锁的时候，唤醒被挂起的线程三，线程三执行tryAcquire()方法使用CAS操做来尝试修改state值，若是此时又来了一个线程四也来执行加锁操做，一样会执行tryAcquire()方法。

这种状况就会出现竞争，线程四若是获取锁成功，线程三仍然须要待在等待队列中被挂起。这就是所谓的非公平锁，线程三辛辛苦苦排队等到本身获取锁，却眼巴巴的看到线程四插队获取到了锁。

公平锁执行流程：

image.png

公平锁在加锁的时候，会先判断AQS等待队列中是存在节点，若是存在节点则会直接入队等待，具体代码以下.

公平锁在获取锁是也是首先会执行acquire()方法，只不过公平锁单独实现了tryAcquire()方法：

#java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire():

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

这里会执行ReentrantLock中公平锁的tryAcquire()方法

#java.util.concurrent.locks.ReentrantLock.FairSync.tryAcquire():

static final class FairSync extends Sync {
    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;
    }
}
复制代码

这里会先判断state值，若是不为0且获取锁的线程不是当前线程，直接返回false表明获取锁失败，被加入等待队列。若是是当前线程则可重入获取锁。

若是state=0则表明此时没有线程持有锁，执行hasQueuedPredecessors()判断AQS等待队列中是否有元素存在，若是存在其余等待线程，那么本身也会加入到等待队列尾部，作到真正的先来后到，有序加锁。具体代码以下：

#java.util.concurrent.locks.AbstractQueuedSynchronizer.hasQueuedPredecessors():

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

这段代码颇有意思，返回false表明队列中没有节点或者仅有一个节点是当前线程建立的节点。返回true则表明队列中存在等待节点，当前线程须要入队等待。

image.png

先判断head是否等于tail，若是队列中只有一个Node节点，那么head会等于tail。

接着判断(s = h.next) == null，这种属于一种极端状况，在enq()入队操做中，此时不是原子性操做，可能存在这种状况：

YcAPpD.png

在第一个红框处，例如 线程一 执行完成，此时head已经有值，而还未执行tail=head的时候，此时 线程二 判断 head != tail成立。而接着 线程一 执行完第二个红框处，此时tail = node，可是并未将head.next指向node。而这时 线程二 就会获得head.next == null成立，直接返回true。这种状况表明有节点正在作入队操做。

若是head.next不为空，那么接着判断head.next节点是否为当前线程，若是不是则返回false。你们要记清楚，返回false表明FIFO队列中没有等待获取锁的节点，此时线程能够直接尝试获取锁，若是返回true表明有等待线程，当前线程如要入队排列，这就是体现公平锁的地方。

非公平锁和公平锁的区别： 非公平锁性能高于公平锁性能。非公平锁能够减小CPU唤醒线程的开销，总体的吞吐效率会高点，CPU也没必要取唤醒全部线程，会减小唤起线程的数量

非公平锁性能虽然优于公平锁，可是会存在致使线程饥饿的状况。在最坏的状况下，可能存在某个线程一直获取不到锁。不过相比性能而言，饥饿问题能够暂时忽略，这可能就是ReentrantLock默认建立非公平锁的缘由之一了。

Condition实现原理

Condition简介

上面已经介绍了AQS所提供的核心功能，固然它还有不少其余的特性，这里咱们来继续说下Condition这个组件。

Condition是在java 1.5中才出现的，它用来替代传统的Object的wait()、notify()实现线程间的协做，相比使用Object的wait()、notify()，使用Condition中的await()、signal()这种方式实现线程间协做更加安全和高效。所以一般来讲比较推荐使用Condition

其中AbstractQueueSynchronizer中实现了Condition中的方法，主要对外提供awaite(Object.wait())和signal(Object.notify())调用。

Condition Demo示例

使用示例代码：

/** * ReentrantLock 实现源码学习 * @author 一枝花算不算浪漫 * @date 2020/4/28 7:20 */
public class ReentrantLockDemo {
    static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) {
        Condition condition = lock.newCondition();

        new Thread(() -> {
            lock.lock();
            try {
                System.out.println("线程一加锁成功");
                System.out.println("线程一执行await被挂起");
                condition.await();
                System.out.println("线程一被唤醒成功");
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
                System.out.println("线程一释放锁成功");
            }
        }).start();

        new Thread(() -> {
            lock.lock();
            try {
                System.out.println("线程二加锁成功");
                condition.signal();
                System.out.println("线程二唤醒线程一");
            } finally {
                lock.unlock();
                System.out.println("线程二释放锁成功");
            }
        }).start();
    }
}
复制代码

执行结果以下图：

image.png

这里线程一先获取锁，而后使用await()方法挂起当前线程并释放锁，线程二获取锁后使用signal唤醒线程一。

Condition实现原理图解

咱们仍是用上面的demo做为实例，执行的流程以下：

image.png

线程一执行await()方法：

先看下具体的代码实现，#java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject.await()：

public final void await() throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();
    Node node = addConditionWaiter();
    int savedState = fullyRelease(node);
    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {
        LockSupport.park(this);
        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
            break;
    }
    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
        interruptMode = REINTERRUPT;
    if (node.nextWaiter != null) // clean up if cancelled
        unlinkCancelledWaiters();
    if (interruptMode != 0)
        reportInterruptAfterWait(interruptMode);
}
复制代码

await()方法中首先调用addConditionWaiter()将当前线程加入到Condition队列中。

执行完后咱们能够看下Condition队列中的数据：

image.png

具体实现代码为：

private Node addConditionWaiter() {
    Node t = lastWaiter;
    if (t != null && t.waitStatus != Node.CONDITION) {
        unlinkCancelledWaiters();
        t = lastWaiter;
    }
    Node node = new Node(Thread.currentThread(), Node.CONDITION);
    if (t == null)
        firstWaiter = node;
    else
        t.nextWaiter = node;
    lastWaiter = node;
    return node;
}
复制代码

这里会用当前线程建立一个Node节点，waitStatus为CONDITION。接着会释放该节点的锁，调用以前解析过的release()方法，释放锁后此时会唤醒被挂起的线程二，线程二会继续尝试获取锁。

接着调用isOnSyncQueue()方法是判断当前的线程节点是否是在同步队列中，由于上一步已经释放了锁，也就是说此时可能有线程已经获取锁同时可能已经调用了singal()方法，若是已经唤醒，那么就不该该park了，而是退出while方法，从而继续争抢锁。

此时线程一被挂起，线程二获取锁成功。

具体流程以下图：

image.png

线程二执行signal()方法：

首先咱们考虑下线程二已经获取到锁，此时AQS等待队列中已经没有了数据。

接着就来看看线程二唤醒线程一的具体执行流程：

public final void signal() {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    Node first = firstWaiter;
    if (first != null)
        doSignal(first);
}
复制代码

先判断当前线程是否为获取锁的线程，若是不是则直接抛出异常。 接着调用doSignal()方法来唤醒线程。

private void doSignal(Node first) {
    do {
        if ( (firstWaiter = first.nextWaiter) == null)
            lastWaiter = null;
        first.nextWaiter = null;
    } while (!transferForSignal(first) &&
             (first = firstWaiter) != null);
}

final boolean transferForSignal(Node node) {
    if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
        return false;

    Node p = enq(node);
    int ws = p.waitStatus;
    if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
        LockSupport.unpark(node.thread);
    return true;
}

/** * Inserts node into queue, initializing if necessary. See picture above. * @param node the node to insert * @return node's predecessor */
private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) { // Must initialize
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}
复制代码

这里先从transferForSignal()方法来看，经过上面的分析咱们知道Condition队列中只有线程一建立的一个Node节点，且waitStatue为CONDITION，先经过CAS修改当前节点waitStatus为0，而后执行enq()方法将当前线程加入到等待队列中，并返回当前线程的前置节点。

加入等待队列的代码在上面也已经分析过，此时等待队列中数据以下图：

image.png

接着开始经过CAS修改当前节点的前置节点waitStatus为SIGNAL，而且唤醒当前线程。此时AQS中等待队列数据为：

image.png

线程一被唤醒后，继续执行await()方法中的while循环。

public final void await() throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();
    Node node = addConditionWaiter();
    int savedState = fullyRelease(node);
    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {
        LockSupport.park(this);
        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
            break;
    }
    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
        interruptMode = REINTERRUPT;
    if (node.nextWaiter != null) // clean up if cancelled
        unlinkCancelledWaiters();
    if (interruptMode != 0)
        reportInterruptAfterWait(interruptMode);
}
复制代码

由于此时线程一的waitStatus已经被修改成0，因此执行isOnSyncQueue()方法会返回false。跳出while循环。

接着执行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)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}
复制代码

此时线程一的流程都已经分析完了，等线程二释放锁后，线程一会继续重试获取锁，流程到此终结。

Condition总结

咱们总结下Condition和wait/notify的比较：

  • Condition能够精准的对多个不一样条件进行控制，wait/notify只能和synchronized关键字一块儿使用，而且只能唤醒一个或者所有的等待队列；

  • Condition须要使用Lock进行控制，使用的时候要注意lock()后及时的unlock()，Condition有相似于await的机制，所以不会产生加锁方式而产生的死锁出现，同时底层实现的是park/unpark的机制，所以也不会产生先唤醒再挂起的死锁，一句话就是不会产生死锁，可是wait/notify会产生先唤醒再挂起的死锁。

总结

这里用了一步一图的方式结合三个线程依次加锁/释放锁来展现了ReentrantLock的实现方式和实现原理，而ReentrantLock底层就是基于AQS实现的，因此咱们也对AQS有了深入的理解。

另外还介绍了公平锁与非公平锁的实现原理，Condition的实现原理，基本上都是使用源码+绘图的讲解方式，尽可能让你们更容易去理解。

参考资料：

  1. 打通 Java 任督二脉 —— 并发数据结构的基石 juejin.cn/post/684490…
  2. Java并发之AQS详解https://www.cnblogs.com/waterystone/p/4920797.html
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程