1.AQS（AbstractQueuedSynchronizer）详解

AQS（AbstractQueuedSynchronizer）详解

       AQS,mfc 网页源码下载 the AbstractQueuedSynchronizer, is a fundamental tool for implementing locks and synchronizers, supporting popular constructs like ReentrantLock, CountDownLatch, and Semaphore. It manages waiting threads using a first-in-first-out (FIFO) queue, with a thread acquiring the lock if its predecessor releases it. Initially, it appears to be a fair lock, but threads attempt to lock before joining the queue, resulting in non-fairness if not handled explicitly. This behavior aligns with the synchronization mechanism of the `synchronized` keyword.

       Before diving into AQS, it's essential to understand various lock types: spin locks, Ticket Lock, MCS (Monitor Contention Sensitive) lock, and CLH (Chase the Head) lock. Spin locks involve spinning instead of blocking, while Ticket Locks ensure fairness by assigning tickets. MCS and CLH locks further optimize shared variable usage and synchronization, respectively, with CLH being the model AQS employs for its queue.

       The AQS's core component, the state, is a shared resource indicator managed with getState(), setState(), and compareAndSetState(). Implementing custom synchronizers only requires managing state changes, bypassing queue management tasks. The waitStatus helps track node status, with features like acquiring resources in both exclusive (独占) and shared modes.

       In the exclusive mode, methods like tryAcquire(), addWaiter(), and acquireQueued are involved. tryAcquire() is the custom implementation point for acquiring or releasing resources. The addWaiter() enqueues nodes, while acquireQueued() ensures queue-based waiting. ReentrantLock's lock and unlock behavior employs AQS's exclusive mode, distinguishing between fair and non-fair synchronization based on Sync subclasses.

       Shared mode allows concurrent access, as seen in Semaphore and CountDownLatch, which count available resources rather than exclusive ownership. CountDownLatch uses a count-down mechanism, while CyclicBarrier relies on ReentrantLock's condition interface to manage waiting threads.

       The Condition interface, implemented by ConditionObject, introduces condition queues to manage threads waiting for specific conditions. The await() method adds nodes to the queue and releases resources, while signal() wakes the first node, moving it to the end.