建站宝盒哪个牌子好学习软件的网站
一、Node 类的结构与队列示意
首先映入眼帘的是 “Node 类的结构与队列示意” 图（见图 1）。在 AQS 的世界里，Node 类扮演着举足轻重的角色，它是构建同步队列和条件队列的基本单元。
从图左侧的代码部分可以清晰地看到，Node 类定义了两种至关重要的模式：共享模式（SHARED）和独占模式（EXCLUSIVE）。共享模式常用于多个线程可以同时访问资源的场景，比如在使用 Semaphore 控制资源访问数量时；而独占模式则适用于同一时间只有一个线程能够访问资源的情况，典型的例子就是 ReentrantLock。
同时，Node 类还拥有五种不同的状态，它们各自肩负着独特的使命：
CANCELLED（值为 1）：当线程由于超时或者中断等原因被取消时，节点会进入此状态，不再参与同步操作。
SIGNAL（值为 -1）：表示当前节点的后继节点包含的线程需要被唤醒（unpark），以便后继线程能够去竞争资源。
CONDITION（值为 -2）：说明当前节点正在等待某个特定条件，此时它处于条件队列中。
PROPAGATE（值为 -3）：在共享模式下，该状态表示后续的 acquireShared 操作能够得以顺利执行。
值为 0：意味着当前节点在同步队列中，正静静地等待获取锁。
此外，Node 类还包含了一系列关键属性，如 waitStatus（用于记录节点状态）、prev（指向前驱节点）、next（指向后继节点）、thread（对应着节点所关联的线程）以及 nextWaiter（主要用于条件队列，指向下一个等待者）。
图右侧则生动地展示了 CLH 队列和条件队列的结构。CLH 队列主要用于实现线程同步，当线程获取资源失败时，它就会加入到这个队列中耐心等待。而条件队列则与 Condition 紧密配合，专门用于线程等待特定条件满足时的队列管理。
二、线程获取资源与 CLH 队列操作
接下来，让我们聚焦于 “线程获取资源与 CLH 队列操作” 图（见图 2）。这张图详细地描绘了多个线程在竞争资源时与 CLH 队列的精彩交互过程。
当线程 A、B、C、D 纷纷尝试获取资源时，会出现两种截然不同的情况：
获取资源成功：当线程幸运地获取到资源后，它会立即进入临界区执行相应的代码。一旦执行完毕，它会及时唤醒队列首部的节点，从而给予等待的线程获取资源的宝贵机会。
获取资源失败：倘若获取资源失败，线程会通过 CAS 操作（即比较并交换，尝试将新节点设置为队列尾部）自旋入队。这种巧妙的方式能够确保线程安全地入队，有效避免了多线程竞争下可能出现的混乱局面。
在 CLH 队列中，我们可以清晰地观察到节点的具体结构和状态变化。头部节点的 waitStatus 为 SIGNAL，这表明它需要唤醒后继节点；而后续节点的 waitStatus 为 0，则表示它们正在安静地等待获取资源。每个节点都准确地记录了对应的线程，清晰地展现了线程在队列中的等待情况。
三、CLH 队列与条件队列的交互
最后，让我们一同审视 “CLH 队列与条件队列的交互” 图（见图 3）。这张图深刻地揭示了 CLH 队列和条件队列之间的转换关系，以及线程在两个队列间的动态移动过程。
当 CLH 队列中的线程执行 await 方法时，对应的线程会优雅地出队，并构建新的条件节点加入到条件队列中。而非 CLH 队列中的线程执行 await 方法时，则会直接进入条件队列。
当条件满足，signal 操作被调用时，条件队列的 firstWaiter 节点会迅速出队，并加入 CLH 队列尾部，等待获取资源。通过这样的交互，AQS 实现了线程的同步和等待 - 唤醒机制，确保了多线程环境下资源的有序访问。
