AQS是 Java 并发工具的“骨架”，它隐藏在 ReentrantLock、Semaphore、CountDownLatch 等看似不同的同步器背后。为什么它能成为并发主要，先把开发者常见的痛点摆出来随后再揭开 AQS 的神秘面纱。

从痛点回顾来看。为什么原生 synchronized 让人抓狂

许多 Java 开发者在使用 synchronized 时频繁遇到以下难题：

• 无超时机制——线程一旦阻塞，只能等待到底，无法设定“X 秒没拿到就放弃”。按理说，
• 缺乏公平性选择——JVM 的 monitor 唤醒策略不确定。可能导致某些线程长期饥饿。
• 无法响应中断——在 synchronized 块内被阻塞时Thread.interrupt 几乎无效。
• 锁语义固定死——想实现读写分离锁或信号量等自定义语义。只能自己从零手搓等待队列，代码易出错且性能不稳定。

这些痛点迫使开发者去自己实现排队、挂起、唤醒逻辑，导致重复劳动与潜在错误。

AQS 的诞生背景：从 monitor 到 CLH 锁的演进

AQS 的前身可以追溯到 Java 时代最早的 monitor 模型，它把锁和等待队列封装在对象内部。因为服务端程序对高并发的需求提高，monitor 在性能与功能上暴露出明显短板。于是工程师们开始尝试各种手工排队方案。

旧方案为何不足？典型案例剖析

• synchronized 手写等待逻辑功能贫瘠且每位开发者都要重新发明轮子。
• 自旋锁适合极短时间竞争，但长时间占用会导致 CPU 空转消耗。
• FIFO 链表 + 全局锁保护排队本身成为热点竞争点，进一步拖累性能。

The core issue isn't “wher to queue” but “how to maintain a correct,efficient,interruptible and timeout‑friendly queue using minimal CAS operations.” This pure data‑structure problem demanded a dedicated abstraction.

Dick Lea 与 CLH 队列变形的突破之路

Dick Lea 在 JDK 发布后的 concurrent 包里引入了 CLH 锁思路。并对其进行改造：

• Migrated from pure spinning to blocking
• Adds a bidirectional linked list for waiters.

  This hybrid design既保留了 CLH 的低争用优势，又兼顾了长时间等待场景。AQS 就是在此基础上正式出现的。

  AQS 源码剖析：一个 state + 两个抽象方法的极简设计