这篇文章主要介绍“Java中的AQS同步队列问题怎么解决”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“Java中的AQS同步队列问题怎么解决”文章能帮助大家解决问题。
AQS
是 AbstractQueuedSynchronizer 的缩写,他是一个抽象同步类,为 JUC
包下的大多数同步工具提供了核心实现,例如 ReentrantLock 的底层就是使用同步队列。AQS 提供一套基础的机制来实现线程的同步、阻塞与唤醒、等待队列等功能,也就是想要深入学习线程工具类,这个同步队列就必须得掌握。
下面是整个 AQS
的类结构实现(从源码中直接打印的图,平常学习源码也可以这样打印出来观察整个程序的运行情况,有助于理解),从图中我们不难发现 AQS
内部持有两个 Node 类型的 head 、tail 属性,我们在什么时候会接触到头尾节点的定义,大家都是有经验的开发人员,肯定都能想到是链表当中。
在属性列中我们可以看见一个 state:int
这样的一个状态字段,Lock 的重入特性就是根据此来实现的,可以表示当前线程的锁重入次数。整个类继承自 AbstractOwnableSynchronizer 类,自然拥有对于其父类中属性的一些控制权,而里面的 Thraed
的线程就是表示当前持有锁的线程,在整个锁过程中具有很重要的地位。
当然链表只是一种组织存储形式的一种数据结构,这里叫做 FIFO
双向队列,至于为什么是双向的呢,看一下 Node
的节点定义就能明白,一个节点中含有 prev 、next 节点来快速访问前驱和后继节点,不就是典型的双向形式呢。
相信大家在看到这个类字段的属性名定义之后就能才出来其的作用,但是这里还是介绍一下主要的几个字段含义,印证大家的猜想。
属性 | 作用 |
---|---|
thread | 表示当前节点封装的具体线程 |
SHARED | 表示当前线程是获取共享资源时被阻塞 |
EXCLUSIVE | 表示当前线程是获取独占资源时被挂起 |
prev | 当前节点的前驱节点 |
next | 当前节点的后继节点 |
waitStatus | 记录当前线程的等待状态,其状态取值就是下面的四个字段 |
CANCELLED | 取消线程 |
SIGNAL | 线程需要被唤醒 |
CONDITION | 线程在 condition 中等待 |
PROPAGATE | 释放共享资源时需要通知其余节点线程 |
上面我们知道了 AQS
其实就是一个双向的队列,如下图的结构一样。在线程获取锁失败的情况下,会被封装成一个 Node 节点而插入到队列当中;当其他的线程释放锁之后又会从队列中唤醒一个节点去争抢锁。
通过源码我们可以发现,在 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; } }
追加节点的操作就是简单的链表尾部添加节点的过程了,这里就不做过多的赘述。这里来看看前面初始化时会添加一个额外的节点在队列中,其实这个节点就是代表当前已经获取了锁的线程,至于为什么这么设置,大家往后看就明白了。
在进行线程唤醒的过程中,会优先唤醒当前持有锁线程的下一个节点线程。
head 指针指向下一个节点;
原来头结点的 next 指向 null;
当前头结点的 prev 指向 null;
当前头结点的 thread 指向 null。
这样就完成线程的唤醒操作了,但是这样来讲其实是不完美的,因为 AQS
只是一个抽象的统一工具,本身并没有对业务进行规范,还是要结合具体的实现类,例如 ReentrantLock 、CountDownLatch 、CyclicBarrier 这些的执行过程来进行分析。
关于“Java中的AQS同步队列问题怎么解决”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注亿速云行业资讯频道,小编每天都会为大家更新不同的知识点。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。