为什么 AQS 成为 Java 并发的基石？

一个问题也许每个写过synchronized的 Java 程序员都曾模糊地想过为什么ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock——这些看起来功能完全不同的并发工具——内部却共享着同一套骨架答案藏在一个不起眼的抽象类里AbstractQueuedSynchronizer简称 AQS。它没有一句业务逻辑却撑起了整个 Java 并发大厦。这不是巧合而是一场发生在 2000 年代初、关于”如何驯服锁”的工程运动的终点。故事背景monitor 的黄金时代与它的裂缝Java 1.0 时代并发的答案只有一个词synchronized。这是 James Gosling 团队从 Hoare 和 Brinch Hansen 在 1970 年代提出的”管程”Monitor模型里直接搬来的设计——每个对象自带一把锁wait()/notify()负责协调。这个设计在当时是相当先进的。管程理论本身就是为了解决比信号量更容易出错的并发编程而生的把锁和等待队列封装进对象内部程序员不用再手动摆弄P()/V()操作。但进入 2000 年代服务端 Java 开始承载真实世界的高并发系统——Web 容器、消息中间件、数据库连接池。工程师们发现synchronized有一堆无法绕过的短板没有超时机制。线程一旦阻塞只能死等或者被interrupt没有”等 3 秒拿不到就放弃”这种选项。不支持公平性选择。JVM 内置的 monitor 唤醒策略是不确定的可能造成某些线程长期饥饿。无法响应中断。线程在synchronized块里阻塞时Thread.interrupt()基本无能为力。锁语义固定死。你没法自己实现一把”读写分离”的锁或者一个”允许 N 个线程同时通过”的信号量——除非从零手搓一套等待队列。而”从零手搓”正是当时的常见做法每一种同步工具都自己维护一个链表或队列自己处理线程的挂起和唤醒自己应对虚假唤醒spurious wakeup、竞态条件、内存可见性。代码重复、极易出错而且性能参差不齐——因为每个人对”如何高效地排队等锁”的理解深度都不一样。旧方案为什么不够用在 AQS 出现之前业界已经尝试过不少排队等锁的方案各有各的道理也各有各的死角。基于synchronized手写等待逻辑简单但如前所述功能贫瘠且每个开发者重新发明轮子质量参差不齐。自旋锁Spin Lock线程不断轮询锁状态避免了线程上下文切换的开销。在锁持有时间极短、CPU 核心充裕的场景下很快但一旦锁被长时间占用自旋线程会疯狂空转白白烧掉 CPU。简单的 FIFO 链表队列 全局锁保护用一把”锁的锁”来保护等待队列本身的增删操作。这带来了新的瓶颈——排队这件事本身又变成了一个热点竞争点高并发下反而互相拖累。真正棘手的问题不是”要不要排队”而是如何用尽可能少的 CASCompare-And-Swap操作、尽可能不加锁的方式维护一条正确、高效、可中断、可超时的等待队列。这是一个纯粹的数据结构与并发算法问题而不是业务问题——这正是它需要被单独抽象出来的原因。真正的突破Doug Lea 与 CLH 队列的变形2004 年JDK 5 发布java.util.concurrent包横空出世。这背后的主要设计者是 Doug Lea——纽约州立大学奥斯威戈分校的教授也是 Java 社区流程JCP中 JSR-166 提案的负责人。Doug Lea 早年做过大量关于并发数据结构与算法的研究他没有从零发明一种排队算法而是敏锐地借用并改造了一个已有的学术成果CLH 锁。CLH 锁得名于三位发明者——Travis Craig、Erik Landin、Anders Hagersten最早是为了解决多处理器系统中的自旋锁扩展性问题而提出的一种链式队列锁。它的巧妙之处在于每个等待的线程只需要自旋检测”前一个节点”的状态而不是竞争同一个共享变量从而把竞争压力分散到了整条链上极大缓解了多核环境下的总线争用。Doug Lea 把这个思路做了一次关键的改造原始 CLH 是纯自旋的不适合等待时间可能很长的锁场景自旋会白白耗电、耗 CPU。他把它改造成了一个双向链表并引入了线程的阻塞park与唤醒unpark机制——排在队列前面的线程可以自旋一小段时间尝试抢锁抢不到就彻底挂起把 CPU 让出来被释放锁的线程负责显式唤醒队列中的下一个节点。这个设计后来被写进了他 2004 年发表的论文《The java.util.concurrent Synchronizer Framework》AQS 由此诞生。源码里的体现一个 state两个抽象方法AQS 的核心其实极简只有一个volatile int state和一个 CLH 变体队列。真正体现设计哲学的是它的入队尝试逻辑public final void acquire(int arg) { if (!tryAcquire(arg) acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }这一行代码值得细品。tryAcquire是一个留白的方法AQS 本身完全不实现它只是先调用一下看子类”你能不能直接拿到锁”。拿到了直接返回队列都不用碰。拿不到才会走addWaiter把当前线程包装成节点塞进等待队列然后在acquireQueued中反复尝试获取、必要时挂起。这是一种典型的模板方法模式AQS 负责”排队、挂起、唤醒”这套通用而复杂的机制把”到底什么叫拿到锁”这个业务判断完全下放给子类。ReentrantLock里tryAcquire判断的是”state 是否为 0或者当前线程是不是已经持有这把可重入锁”Semaphore里判断的是”剩余许可证数量是否大于 0”CountDownLatch里判断的是”计数器是否已经归零”。同一套排队引擎装上不同的判断逻辑就变成了完全不同的并发工具。设计思想把”排队”这件事彻底工程化AQS 集中体现了几种经典的工程思想模板方法模式框架定骨架子类填血肉tryAcquire/tryRelease/tryAcquireShared/tryReleaseShared都是留给子类的钩子。CAS 无锁编程state的更新几乎全部通过compareAndSet完成避免了”锁保护锁”的悖论。先自旋、后阻塞在真正调用LockSupport.park()让出 CPU 之前会先做有限次数的快速重试兼顾了短期竞争下的低延迟和长期等待下的低功耗。独占与共享两种模式ReentrantLock用独占模式同一时刻只有一个线程能拿锁Semaphore、CountDownLatch、ReentrantReadWriteLock的读锁用共享模式多个线程能同时通过。同一条队列、同一套唤醒逻辑靠一个模式位区分行为这是极致的复用。为什么它最终赢了因为它把”造一把新锁”这件事的门槛从”你得懂多线程内存模型和无锁队列”降低到了”你只需要写清楚一个state该怎么增减”。ReentrantLock、ReentrantReadWriteLock、Semaphore、CountDownLatch、FutureTask、ThreadPoolExecutor内部的 Worker 线程控制全部构建在 AQS 之上。此后整个 Java 生态里几乎所有需要”自定义同步语义”的场景第一反应都是”继承 AQS”而不是”自己写队列”。这也是为什么后来大量开源项目比如 Netty 的部分同步组件、各种连接池实现都选择直接复用或模仿这套框架而不是重新发明。它真正改变的不是某一个 API而是”实现同步器”这件事本身的抽象层级——从算法问题变成了配置问题。有没有更好的方案今天会不会不一样如果今天重新设计一些边界确实已经开始松动。Project Loom 带来的虚拟线程JDK 21 正式发布改变了”线程”本身极其昂贵的前提——过去 AQS 拼命省着用的挂起/唤醒开销在虚拟线程的世界里成本结构完全不同了。JDK 团队为此专门对synchronized做了改造让虚拟线程在阻塞时不再固定占用宝贵的平台线程Carrier ThreadReentrantLock系的 AQS 体系本身在这方面反而比传统synchronized更早就对虚拟线程友好因为它从来就是基于用户态调度、而不依赖 JVM monitor 的。StampedLockJDK 8 引入在读多写少的场景下用乐观读的方式进一步减少了 CAS 竞争是 AQS 思路的一次延伸而非替代。但 AQS 的核心骨架——”用一个原子状态位加一条无锁化的等待队列来解耦排队机制和业务语义”——这个思想本身并没有过时。硬件在变语言特性在变,但”多个执行流竞争一个有限资源”这个问题的数学本质没有变。现实中的应用ReentrantLock、ReentrantReadWriteLock、Semaphore、CountDownLatch、CyclicBarrier的部分实现、FutureTask、线程池ThreadPoolExecutor的任务执行控制——几乎整个 JDK 并发包的骨架都建立在 AQS 上。这也是为什么无数依赖 JDK 并发工具的框架——Tomcat 的连接管理、各种数据库连接池、限流组件——本质上都在间接使用这套排队引擎。一句话总结优秀的并发框架从不是发明一种更聪明的锁而是把”排队”这件最容易出错、最难写对的事情从每个人的手里收回到一个被反复验证过的骨架里。