Java中的AQS同步队列问题详解

目录

• AQS 同步队列
• 1、AQS 介绍
• 1.1、类图关系
• 1.2、节点剖析
• 2、AQS 实现原理
• 2.1、队列初始化
• 2.2、追加节点
• 3、AQS 唤醒动作

AQS 同步队列

1、AQS 介绍

AQS 是 AbstractQueuedSynchronizer 的缩写，他是一个抽象同步类，为 JUC 包下的大多数同步工具提供了核心实现，例如 ReentrantLock 的底层就是使用同步队列。AQS 提供一套基础的机制来实现线程的同步、阻塞与唤醒、等待队列等功能，也就是想要深入学习线程工具类，这个同步队列就必须得掌握。

1.1、类图关系

下面是整个 AQS 的类结构实现（从源码中直接打印的图，平常学习源码也可以这样打印出来观察整个程序的运行情况，有助于理解），从图中我们不难发现 AQS 内部持有两个 Node 类型的 head 、tail 属性，我们在什么时候会接触到头尾节点的定义，大家都是有经验的开发人员，肯定都能想到是链表当中。

在属性列中我们可以看见一个 state:int 这样的一个状态字段，Lock 的重入特性就是根据此来实现的，可以表示当前线程的锁重入次数。整个类继承自 AbstractOwnableSynchronizer 类，自然拥有对于其父类中属性的一些控制权，而里面的 Thraed 的线程就是表示当前持有锁的线程，在整个锁过程中具有很重要的地位。

1.2、节点剖析

当然链表只是一种组织存储形式的一种数据结构，这里叫做 FIFO 双向队列，至于为什么是双向的呢，看一下 Node 的节点定义就能明白，一个节点中含有 prev 、next 节点来快速访问前驱和后继节点，不就是典型的双向形式呢。

相信大家在看到这个类字段的属性名定义之后就能才出来其的作用，但是这里还是介绍一下主要的几个字段含义，印证大家的猜想。

2、AQS 实现原理

上面我们知道了 AQS 其实就是一个双向的队列，如下图的结构一样。在线程获取锁失败的情况下，会被封装成一个 Node 节点而插入到队列当中；当其他的线程释放锁之后又会从队列中唤醒一个节点去争抢锁。

2.1、队列初始化

通过源码我们可以发现，在 AQS 进行初始化的时候的并没有对 head 、tail 进行初始化，而这两个节点是控制整个队列的，也就是说一开始整个队列处于 null 状态。

protected AbstractQueuedSynchronizer() {}

当第一个线程争抢锁失败之后会封装成 Node 进入到同步队列当中，这个时候就会进行判断，如果当前队列为空就会进行初始化（未进行初始化），初始化完成之后就将当前线程节点接在队列的尾部。

private final void initializeSyncQueue() {
    Node h;
    if (HEAD.compareAndSet(this, (Void)null, h = new Node())) {
        this.tail = h;
    }
}

2.2、追加节点

追加节点的操作就是简单的链表尾部添加节点的过程了，这里就不做过多的赘述。这里来看看前面初始化时会添加一个额外的节点在队列中，其实这个节点就是代表当前已经获取了锁的线程，至于为什么这么设置，大家往后看就明白了。

3、AQS 唤醒动作

在进行线程唤醒的过程中，会优先唤醒当前持有锁线程的下一个节点线程。

• head 指针指向下一个节点；
• 原来头结点的 next 指向 null；
• 当前头结点的 prev 指向 null；
• 当前头结点的 thread 指向 null。

这样就完成线程的唤醒操作了，但是这样来讲其实是不完美的，因为 AQS 只是一个抽象的统一工具，本身并没有对业务进行规范，还是要结合具体的实现类，例如 ReentrantLock 、CountDownLatch 、CyclicBarrier 这些的执行过程来进行分析。

到此这篇关于Java中的AQS同步队列的文章就介绍到这了,更多相关java AQS同步队列内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！