这是本人署名原创文章，未经许可不允许转载。另外，这也是本人劳动成果，切勿抄袭，侵权必究。本公众号所有文章均为原创，如果您感兴趣请关注。谢谢！
之前我写了一遍讲解ConditionObject如何实现条件队列的文章，有些拘泥实现细节、讲得不够清晰。本文再次把ConditionObject的主体实现逻辑讲解一遍，把关键的实现要点总结出来，形成要点。看完这篇文章可以保证你不必再去阅读ConditionObject的源码并且已经深度掌握其实现细节，保证你今后写代码、面试、分析问题够用了。
1. 首先，条件队列ConditionObject作为
AbstractQueuedSynchronized（以下简称AQS）的非静态内部类，通过AQS.this引用外部类实例(如图1)。为什么需要这种关联？因为多个线程可能会并发调用await()，而await()需要修改共享的条件队列（一个单链表和AQS上的同步队列，把线程结点在这两个队列之间移动。为了保证并发访问的线程安全性，需要锁来保护，而外部类AQS正是提供锁功能的，所以ConditionObject以这种方式关联AQS类。所以，ConditionObject需要AQS锁来以独占方式修改条件队列和同步队列，ConditionObject内部不再考虑如何修改共享数据，这就是为什么使用Condition前必须先持有锁的原因。
2. 其次，AQS提供一个同步队列（用于实现锁），而ConditionObject提供一个条件队列，且AQS可以关联多个条件队列，如下图所示。在同步队列中的线程结点处在对于锁的竞争中，而在条件队列中等待的线程并不竞争锁，而是在等待其他线程的信号，即调用signal()。
3. await操作：线程经过竞争得到了锁然后才会调用await()，所以此时同步队列上不会有对应当前线程的结点。在await()操作中，首先把当前线程结点放入等待队列，然后释放锁。在释放锁的时候，会将锁的状态保存到当前线程的栈中（局部变量），然后锁的占有状态释放以后，执行一个唤醒动作（通过LockSupport.unpark完成，唤醒同步队列中的一个线程），让其他线程有机会竞争AQS锁。而当前线程进入一个循环体，不断判断自己是否在同步队列上（刚调用的时候已经不在同步队列上了），如果不是，则阻塞自己；如果是，则跳出循环（因为其他线程调用signal，会把本线程重新放到同步队列上，设计很巧妙）。当跳出循环以后，去竞争AQS锁。当得到了AQS锁之后，await()才正常返回。**注意，await()返回之后已经重新持有锁。**流程如下：
4. signal操作： 唤醒线程首先必须已经持有AQS锁，然后调用signal()，这样才能放心地操作同步队列和条件队列。signal()首先找到条件队列的第一个结点a，把它从队列中取出来，状态改为条件等待（waitStatus=2），然后把它放入到AQS的同步队列，然后根据锁的等待情况（同步队列中，节点a之前的结点b）唤醒这个线程，或者让它保持阻塞状态。在以上操作过程中，如果结点a对应的线程执行了取消动作（例如通过中断、计时），那么在条件队列中找下一个结点，继续按上面的步骤操作。对于signal()操作而言，只转移成功一个线程结点就结束；而对于signalAll()而言，需要把所有线程结点全部转移到同步队列。这里需要注意，signal()和signalAll()执行完后，不会释放锁。
总目录展示
该笔记共八个节点（由浅入深），分为三大模块。
高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。
一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。
高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。
篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）
由于内容太多，这里只截取部分的内容。
存中…(img-pD48FbtZ-1714365525506)]
由于内容太多，这里只截取部分的内容。
201
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
