抽象队列同步器（AQS）的原理与应用

最新推荐文章于 2025-12-02 21:20:38 发布

原创最新推荐文章于 2025-12-02 21:20:38 发布 · 930 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#AQS #java #springboot

文章目录

- 引言

引言

在现代企业级应用开发中，Spring Boot 已成为构建微服务和独立应用的首选框架。为了编写出高性能、高并发且线程安全的应用，深入理解 Java 并发编程的核心机制至关重要。抽象队列同步器（AbstractQueuedSynchronizer，简称 AQS）正是 Java 并发包（java.util.concurrent，简称 JUC）的基石。它是一个用于构建锁和同步器的核心框架。诸如 ReentrantLock、Semaphore、CountDownLatch 等我们耳熟能详的同步工具，其内部实现都离不开 AQS 的支持。

第一部分：AQS 核心原理深度解析

AQS 的设计精髓在于它为同步器的实现提供了一个标准化的模板。开发者无需关心线程的排队、阻塞、唤醒等底层复杂操作，只需专注于同步状态的管理逻辑即可。

1.1 设计思想：模板方法模式

AQS 完美地运用了模板方法模式。它定义了同步操作的骨架，例如获取同步状态（acquire）和释放同步状态（release），但将具体的状态变更逻辑延迟到子类中实现。子类需要根据自身的同步语义，重写以下受保护的方法：

tryAcquire(int arg): 尝试以独占模式获取资源。
tryRelease(int arg): 尝试以独占模式释放资源。
tryAcquireShared(int arg): 尝试以共享模式获取资源。
tryReleaseShared(int arg): 尝试以共享模式释放资源。
isHeldExclusively(): 判断当前线程是否持有独占锁。

AQS 的公共方法（如 acquire, release）会调用这些由子类实现的 try* 方法，并负责处理获取失败后的线程排队和获取成功后的线程唤醒等一系列工作。

1.2 核心数据结构与组件

AQS 的内部机制主要围绕三个核心组件构建： 状态（State） 、 等待队列（Wait Queue） 和 节点（Node）。

同步状态 (State)
AQS 内部通过一个 private volatile int state; 变量来表示同步状态。volatile 关键字保证了该状态在多线程之间的可见性。对 state 的所有修改都通过 CAS（Compare-And-Swap）操作来保证原子性，这是 AQS 实现线程安全的关键。
- 在 ReentrantLock 中，state 表示锁的重入次数。
- 在 Semaphore 中，state 表示剩余的许可数量。
- 在 CountDownLatch 中，state 表示计数器的值。
等待队列 (Wait Queue)
当一个线程尝试获取同步状态失败时，它不会原地自旋，而是被封装成一个节点加入到一个先进先出（FIFO）的双向队列中进行等待。这个队列是 CLH (Craig, Landin, and Hagersten) 锁队列的一个变体，它高效地管理着所有等待线程，避免了“惊群效应”，即唤醒的线程总是队列的头部节点。
节点 (Node)
队列中的每个元素都是一个 Node 对象。Node 类是 AQS 的一个静态内部类，它代表了一个等待获取同步状态的线程。其关键属性包括：
- waitStatus: 节点的状态，是一个 int 值。主要有 CANCELLED（1，线程已取消）、SIGNAL（-1，后继节点需要被唤醒）、CONDITION（-2，节点在条件队列中等待）、PROPAGATE（-3，用于共享模式下的状态传播）等。SIGNAL 状态是保证线程唤醒机制正常工作的核心。
- prev 和 next: 分别指向前驱和后继节点的指针，构成了双向链表。
- thread: 封装了当前节点所代表的线程。
- SHARED 和 EXCLUSIVE: 静态常量，用于标识节点的模式是共享模式还是独占模式。

1.3 两种资源共享模式

AQS 支持两种不同的资源共享模式，以满足不同的并发场景需求。

独占模式 (Exclusive Mode): 同一时刻只允许一个线程获取同步状态。ReentrantLock 就是典型的独占模式实现。当一个线程调用 acquire() 方法时，如果成功（例如，通过 CAS 将 state 从 0 改为 1），则该线程持有锁；如果失败，则线程进入等待队列并被挂起。当持有锁的线程调用 release() 方法时，state 会被更新，并且队列头部的下一个等待线程会被唤醒。
共享模式 (Shared Mode): 允许多个线程同时获取同步状态。Semaphore 和 CountDownLatch 是共享模式的经典应用。当一个线程调用 acquireShared() 时，如果 state 的值满足条件（例如，Semaphore 的许可数大于 0），则线程获取成功；否则进入等待队列。当有线程调用 releaseShared() 时，除了会更新 state，还可能会唤醒队列中一个或多个等待的线程，以实现状态的传播（PROPAGATE）。

2.4 条件变量 (ConditionObject)

AQS 还提供了一个内部类 ConditionObject，它实现了 Condition 接口。每个 ConditionObject 实例都与一个独占锁关联，并维护着一个独立的条件等待队列。它提供了 await()、signal() 和 signalAll() 等方法，功能类似于 Object 的 wait()、notify() 和 notifyAll()，但功能更强大，例如支持多个条件队列，提供了更灵活的线程间协作机制。

第二部分：基于 AQS 的同步工具在 Spring Boot 中的应用

一个常见的误区是认为 Spring Boot 框架自身的核心组件直接继承或大量使用了 AQS。经过深入分析，Spring 框架和 Spring Boot 的核心容器、自动配置等模块中，并没有直接暴露基于 AQS 的自定义实现。

然而，这丝毫不影响 AQS的重要性。因为任何 Spring Boot 应用本质上都是一个 Java 应用，其业务逻辑、所依赖的中间件（如数据库连接池、消息队列客户端）以及并发任务处理，都不可避免地会大量使用 JUC 包提供的同步工具。因此，理解 AQS 是编写高质量 Spring Boot 应用的内功心法。

2.1 常见同步工具的应用场景

以下是在 Spring Boot 项目中，基于 AQS 的同步工具的典型应用场景：

ReentrantLock：精细化并发控制
- 场景：当内置的 synchronized 关键字无法满足需求时，ReentrantLock 是首选。例如，在需要实现公平锁、可中断的锁获取、或尝试非阻塞地获取锁的业务场景中。在 Spring Boot 的 Service 中，可以用它来保护一个共享的业务资源，如一个全局配置或一个有状态的单例 Bean 。
- 示例：在一个库存管理服务中，对某个商品的库存更新操作需要加锁，使用 ReentrantLock 可以防止超卖，并可以设置超时等待，避免线程长时间阻塞。
Semaphore：流量控制与资源池管理
- 场景：控制对特定资源的并发访问数量，是实现限流的利器。在 Spring Boot 应用中，可以用来限制对某个第三方 API 的并发调用数，或者限制同时执行某个计算密集型任务的线程数，以保护系统免受过载冲击。
- 示例：假设一个服务需要调用一个昂贵的外部服务，且该服务有并发限制。可以使用 Semaphore 初始化一个许可数量，在调用前 acquire()，调用结束后 release()，从而优雅地实现客户端侧的限流。
CountDownLatch：多任务协同
- 场景：一个线程需要等待一个或多个其他线程完成某些操作后才能继续执行。这在 Spring Boot 的异步任务（@Async）处理中非常常见。例如，一个 API 请求需要并行调用多个下游微服务，然后聚合所有结果返回给客户端。主线程可以使用 CountDownLatch 等待所有异步调用完成。
- 示例：在启动应用时，需要并行初始化多个资源（如加载缓存、建立连接），主启动线程可以创建一个 CountDownLatch，每个初始化任务完成后 countDown()，主线程则 await() 直到所有资源准备就绪。
ReentrantReadWriteLock：优化读多写少场景
- 场景：当共享资源被读取的频率远高于被写入的频率时，使用读写锁可以显著提升并发性能。它允许多个线程同时持有读锁，但写锁是独占的。这非常适合在 Spring Boot 应用中实现本地缓存。
- 示例：实现一个简单的应用内参数缓存服务。读取缓存时获取读锁，多个请求可以并发读取。当需要更新缓存时，获取写锁，此时所有读写操作都将被阻塞，确保数据一致性。

第三部分：自定义 AQS 同步器并在 Spring Boot 中集成

尽管 JUC 提供的工具已经非常丰富，但在某些极端复杂的业务场景下，我们可能需要自定义同步语义。这时，继承 AQS 就是最佳选择。

3.1 实现一个自定义同步器：`MutexLock`

下面我们实现一个简单的、不可重入的独占锁 MutexLock。

import java.util.concurrent.locks.AbstractQueuedSynchronizer;

// 自定义不可重入独占锁
public class MutexLock {

    // 静态内部类，继承AQS
    private static class Sync extends AbstractQueuedSynchronizer {
        // 判断是否处于锁定状态
        @Override
        protected boolean isHeldExclusively() {
            return getState() == 1;
        }

        // 尝试获取锁
        @Override
        protected boolean tryAcquire(int arg) {
            // 使用CAS操作，期望state为0，如果成功则设置为1
            if (compareAndSetState(0, 1)) {
                setExclusiveOwnerThread(Thread.currentThread());
                return true;
            }
            return false;
        }

        // 尝试释放锁
        @Override
        protected boolean tryRelease(int arg) {
            if (getState() == 0) {
                throw new IllegalMonitorStateException();
            }
            setExclusiveOwnerThread(null);
            setState(0); // 直接设置为0，因为不可重入
            return true;
        }
    }

    private final Sync sync = new Sync();

    public void lock() {
        sync.acquire(1);
    }

    public void unlock() {
        sync.release(1);
    }
}

这个示例清晰地展示了如何通过继承 AQS 并重写 tryAcquire 和 tryRelease 方法来定义锁的核心逻辑。

3.2 在 Spring Boot 中集成自定义同步器

我们可以轻易地将这个 MutexLock 集成到 Spring Boot 应用中。

注册为 Spring Bean：
在配置类中，将 MutexLock 声明为一个 Bean。

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ConcurrencyConfig {
    @Bean
    public MutexLock mutexLock() {
        return new MutexLock();
    }
}

在 Service 中使用：
通过依赖注入，在需要同步控制的 Service 中使用这个自定义锁。

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class SharedResourceService {

    @Autowired
    private MutexLock lock;

    private int sharedCounter = 0;

    public void performLockedOperation() {
        lock.lock();
        try {
            // 临界区：保护共享资源
            sharedCounter++;
            System.out.println(Thread.currentThread().getName() + " - Counter: " + sharedCounter);
        } finally {
            lock.unlock();
        }
    }
}

通过这种方式，我们可以将自定义的、符合特定业务需求的同步逻辑无缝地整合到 Spring Boot 的依赖管理体系中。

第四部分：AQS 与 Java 并发新纪元：虚拟线程 (Project Loom)

随着 Java 19+ 引入并最终在 Java 21 成为正式功能的虚拟线程（Project Loom），Java 的并发编程模型正在经历一场革命。Spring Boot 3.x 版本也已全面拥抱虚拟线程，为开发者带来了前所未有的高并发处理能力。

4.1 AQS 在虚拟线程环境下的行为与影响

兼容性与优势：AQS 及其子类（如 ReentrantLock）与虚拟线程完全兼容。更重要的是，在虚拟线程环境下，使用 AQS 系列的锁是官方推荐的最佳实践。这是因为传统的 synchronized 关键字在同步块内执行阻塞操作时，会将虚拟线程“钉住”（Pinning）到底层的平台线程上，这使得平台线程无法被释放去执行其他任务，从而丧失了虚拟线程轻量级调度的核心优势。
调度行为：ReentrantLock 等基于 AQS 的锁在设计上能够与虚拟线程调度器更好地协作。当一个虚拟线程在调用 lock.lock() 时被阻塞，它会挂起并让出（unmount）其占用的平台线程。平台线程可以立即去执行其他就绪的虚拟线程。当锁被释放时，被唤醒的虚拟线程会被重新调度（mount）到任意一个可用的平台线程上继续执行。这个过程不会导致平台线程的实际阻塞，极大地提升了系统吞吐量。
性能影响：在 I/O 密集型的高并发 Spring Boot 应用中，启用虚拟线程并配合使用 ReentrantLock 等 AQS 同步器，可以有效避免线程“钉住”问题，从而获得比传统线程池模型高得多的性能和可伸缩性。

4.2 Spring Boot 3.x 中的调优建议

优先使用 java.util.concurrent.locks：在启用了虚拟线程的 Spring Boot 应用中，对于所有需要同步的代码块，都应优先使用 ReentrantLock 或其他 JUC 锁来替代 synchronized 关键字。
谨慎使用 synchronized：仅在确定同步块内不包含任何阻塞 I/O 操作或长时间计算时，才可考虑使用 synchronized。
保持版本更新：虚拟线程技术和 Spring 框架对其的集成支持仍在快速发展。保持 JDK 和 Spring Boot 到最新版本，是获取最佳性能和稳定性的关键。
监控虚拟线程：使用 Micrometer 等监控工具来跟踪虚拟线程的创建、使用情况，以及是否存在非预期的线程“钉住”现象。