1. 为什么需要AQS：并发编程的痛点与解决方案
在Java并发编程的世界里，每个开发者都会遇到一个根本性难题：如何安全高效地协调多个线程对共享资源的访问？想象一下春运期间的火车站售票系统，如果没有合理的排队和放行机制，成千上万的旅客同时抢票会导致怎样的混乱？这就是并发编程面临的现实挑战。
传统解决方案主要依赖synchronized关键字和基本的wait/notify机制。我在早期项目中使用synchronized时经常遇到这样的困境：一个简单的计数器类，使用synchronized修饰后虽然保证了线程安全，但性能测试显示吞吐量下降了近60%。更糟糕的是，当需要实现超时获取锁、可中断锁等复杂功能时，synchronized显得力不从心。
AQS（AbstractQueuedSynchronizer）的出现正是为了解决这些痛点。它本质上是一个构建锁和同步器的框架，Doug Lea在设计JUC包时创造性地采用了模板方法模式，将资源获取/释放的通用逻辑封装在AQS中，而将具体的资源状态管理交给子类实现。这种设计带来了三大优势：
-
性能优化：通过CLH队列（Craig, Landin, and Hagersten lock queue）的变体实现高效的线程排队，避免了synchronized的重量级锁开销。在我的压力测试中，基于AQS实现的ReentrantLock比synchronized有20%-40%的吞吐量提升。
-
功能扩展：支持公平/非公平锁、条件变量、共享/独占模式等丰富特性。比如在电商秒杀场景中，我们可以轻松实现"等待超时自动返回失败"的业务需求。
-
灵活定制：通过继承AQS可以快速实现各种同步器。去年我们团队仅用200行代码就基于AQS实现了分布式环境下的轻量级同步组件。
关键理解：AQS不是直接面向业务的API，而是JUC包中锁和同步器的"造锁工厂"。它用模板方法模式解耦了同步器的通用排队逻辑和具体资源控制逻辑。
2. AQS核心原理：状态机与CLH队列的完美结合
2.1 状态管理：int变量的艺术
AQS最精妙的设计之一是用一个简单的int类型变量（state）来表示同步状态。这个看似简单的设计蕴含着深刻的工程智慧：
java复制// AQS中的核心状态字段
private volatile int state;
protected final int getState() {
return state;
}
protected final void setState(int newState) {
state = newState;
}
// CAS原子更新状态
protected final boolean compareAndSetState(int expect, int update) {
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
state的语义完全由子类定义，这种灵活性使得AQS可以支持多种同步场景：
- 在ReentrantLock中，state表示锁的重入次数
- 在Semaphore中，state表示可用许可数
- 在CountDownLatch中，state表示剩余计数
我在研究ThreadPoolExecutor源码时发现，其内部Worker类也是基于AQS实现，state在这里被用来表示工作线程的运行状态（0未启动，1运行中）。这种统一的状态管理机制大幅降低了理解成本。
2.2 CLH队列：线程排队的高效实现
当线程获取资源失败时，AQS会将其封装为Node节点加入CLH队列。这个队列有以下几个关键特点：
- 双向链表结构：每个Node保存前驱(pre)和后继(next)指针，支持精确的唤醒控制
- 等待状态：waitStatus字段标记线程状态（CANCELLED、SIGNAL等）
- 无阻塞算法：通过自旋+CAS实现线程安全入队
java复制static final class Node {
volatile int waitStatus;
volatile Node prev;
volatile Node next;
volatile Thread thread;
Node nextWaiter; // 条件队列专用
}
实际开发中遇到过这样的问题：在高并发场景下，简单的LinkedList作为同步队列会导致严重的竞争。AQS的解决方案是：
- 使用volatile变量保证可见性
- 通过CAS保证原子性
- 在竞争激烈时采用"自旋->yield->阻塞"的渐进策略
3. AQS的两种模式与应用场景
3.1 独占模式：ReentrantLock的实现剖析
独占模式最典型的应用就是ReentrantLock。我们通过一个真实案例来看其实现原理：
java复制// 自定义业务锁实现
public class BusinessLock extends AbstractQueuedSynchronizer {
protected boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
protected boolean tryRelease(int releases) {
// 省略实现...
}
}
在电商系统中，我们曾用类似实现创建了具有业务特性的锁：
- 支持最大重入次数限制
- 集成业务指标监控
- 实现锁获取的熔断机制
3.2 共享模式：CountDownLatch的实战技巧
共享模式的典型代表是CountDownLatch。在一次分布式系统压测中，我们巧妙运用CountDownLatch实现了这样的流程：
java复制// 初始化计数器为服务数量
CountDownLatch latch = new CountDownLatch(3);
// 服务调用线程
executor.execute(() -> {
serviceA.call();
latch.countDown();
// 记录日志...
});
// 主控线程
latch.await(5, TimeUnit.SECONDS); // 超时保护
collectResults();
特别提醒：CountDownLatch的state初始化后只能减少不能增加，这点与Semaphore不同。我曾见过有开发者误用CountDownLatch实现动态扩容，正确的做法应该是使用CyclicBarrier。
4. AQS高级特性与性能优化
4.1 条件变量的正确使用姿势
AQS的条件变量（ConditionObject）比Object的wait/notify更强大：
java复制// 典型的生产者消费者实现
public class BoundedBuffer {
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
public void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)
notFull.await(); // 不同于Object.wait()
// ...入队操作
notEmpty.signal();
} finally {
lock.unlock();
}
}
}
关键区别：
- 每个Lock可以创建多个Condition
- 支持awaitUninterruptibly()等增强方法
- 条件队列与同步队列分离，提高吞吐量
4.2 性能优化实战经验
在高并发场景下，AQS的性能调优尤为关键。以下是我们总结的优化checklist：
-
减少CAS竞争：
- 合理设置自旋次数（默认是1次）
- 对于写多读少的state，考虑使用StampedLock
-
避免过早阻塞：
java复制// 优化前 lock.lock(); try { // 业务逻辑 } finally { lock.unlock(); } // 优化后 if (lock.tryLock(50, TimeUnit.MILLISECONDS)) { try { // 业务逻辑 } finally { lock.unlock(); } } else { // 降级处理 } -
监控队列长度：
java复制// 通过反射获取同步队列（生产环境慎用） Field tail = AbstractQueuedSynchronizer.class.getDeclaredField("tail"); tail.setAccessible(true); int queueLength = 0; for (Node p = (Node)tail.get(lock); p != null; p = p.prev) { queueLength++; }
5. AQS常见陷阱与最佳实践
5.1 内存可见性问题
虽然AQS的state字段是volatile的，但子类新增的状态字段也需要正确处理可见性。我们曾遇到过这样的Bug：
java复制public class BuggyLock extends AbstractQueuedSynchronizer {
private boolean isBusy; // 缺少volatile修饰
protected boolean tryAcquire(int arg) {
if (!isBusy) { // 可能读取到过期值
isBusy = true;
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
}
修正方案：
- 所有与同步相关的状态都应使用volatile
- 或者通过getState/setState方法统一管理
5.2 死锁预防策略
基于AQS的锁虽然强大，但使用不当仍会导致死锁。我们的项目规范要求：
- 获取多个锁时，必须定义全局的锁顺序
- 使用tryLock设置超时时间
- 通过ThreadMXBean实现死锁检测
java复制// 死锁检测示例
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] threadIds = bean.findDeadlockedThreads();
if (threadIds != null) {
ThreadInfo[] infos = bean.getThreadInfo(threadIds);
for (ThreadInfo info : infos) {
logger.warn("Deadlock detected: " + info.getThreadName());
}
}
5.3 调试技巧
当AQS出现问题时，可以通过以下方式获取诊断信息：
-
使用jstack查看线程状态：
code复制"Thread-1" #12 prio=5 os_prio=0 tid=0x00007f487c0e8000 nid=0x4a1d waiting on condition [0x00007f48715e6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x000000076c182e08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) -
使用JConsole观察锁竞争情况
-
开启AQS的调试模式（需修改源码重新编译）
6. AQS的现代替代方案
虽然AQS仍然是Java并发包的基石，但随着Java版本更新，一些新特性也值得关注：
-
VarHandle（Java 9+）：
java复制private static final VarHandle STATE; static { try { STATE = MethodHandles.lookup() .findVarHandle(AQS.class, "state", int.class); } catch (ReflectiveOperationException e) { throw new Error(e); } } -
StampedLock：适用于读多写少的场景
-
CompletableFuture：对于异步编程场景更友好
不过根据我们的性能测试，在传统的锁竞争场景下，基于AQS的ReentrantLock仍然是最稳定的选择，特别是在Java 8及以下版本中。