Java并发编程学习笔记：AQS

最新推荐文章于 2024-09-08 12:41:07 发布

YOUChanWill

最新推荐文章于 2024-09-08 12:41:07 发布

阅读量765

点赞数 29

分类专栏： JAVA 文章标签： java juc

本文链接：https://blog.csdn.net/qq_45902224/article/details/136749646

版权

JAVA 专栏收录该内容

10 篇文章 1 订阅

订阅专栏

Java并发编程学习笔记：AQS

一、底层原理
二、锁的公平性
- 公平锁
- 非公平锁
三、容器实现

JUC中的AQS（AbstractQueuedSynchronizer）本质上是一个用于构建线程同步器的框架（抽象队列式同步器），它实现了Java中锁和同步器的底层机制。

一、底层原理

核心功能

同步状态管理

AQS 使用一个受保护的 volatile 类型变量 state 来表示同步状态。 volatile 保证了对 state 变量的读写操作具有原子性和可见性，使得多线程环境下，各线程可以正确地感知到同步状态的变化。
AQS 提供基于 CAS原子指令的操作方法来实现无锁化的状态更新 ，避免了使用传统锁带来的性能开销。

CLH 队列和线程调度机制

AQS 内部维护了一个FIFO的双向队列，每个节点（Node）代表一个尝试获取同步状态但未成功的线程。 这个队列来源于 CLH 锁，通过链表结构和wait-status字段实现线程间的阻塞与唤醒。
当线程无法立即获取到同步状态时，会被构造为一个新的 Node 并加入等待队列尾部； 而当同步状态释放时，根据锁的公平性寻找可被唤醒的线程并将其激活。这一过程涉及挂起线程和恢复线程的执行的方法。

独占模式与共享模式

独占模式： 仅允许一个线程持有同步状态。同一时间只有一个线程能够获取到锁，并且支持重入，即同一个线程可以多次获取而不受限制。
共享模式： 允许多个线程同时持有同步状态，但可能需要遵循某种条件或限制数量，让多个线程可以共享这些资源，直至资源耗尽。

模板方法设计模式

AQS 利用模板方法设计模式，提供了基本的框架和关键算法，子类只需重写几个核心方法即可定制自己的同步器行为。

tryAcquire(int arg)： 尝试获取同步状态，由子类根据其具体逻辑实现。
tryRelease(int arg)： 尝试释放同步状态，同样需要自行定义逻辑。
对于共享模式还有相应的获取与释放方法。

自旋、阻塞与超时机制

AQS 支持自旋等待，在尝试获取同步状态失败后，线程会在一段短暂的时间内循环检查同步状态是否满足获取条件，而不是立即进入阻塞队列。
AQS 支持设置获取同步状态时的超时机制，提供限时等待的功能。

运行流程

下面是一个模拟银行账户取款流程中所涉及到AQS的具体实现。

同步状态管理： 在这个场景中，维护一个volatile变量作为同步状态可以简单理解为“是否持有锁”，初始值通常为0，表示未锁定。当线程尝试获取锁（即取款操作开始前）时，调用tryAcquire()方法，该方法使用CAS原子操作尝试将同步状态从0改为1，如果成功则说明获取到锁。

线程排队与阻塞机制：

如果多个线程同时请求取款，当第一个线程获取到锁后，其他线程会发现同步状态已非0，它们在tryAcquire()中失败。
失败的线程会被封装成一个节点（Node），并加入到AQS内部的CLH双向队列尾部。 每个节点代表一个等待获取锁的线程，并且具有指向前后节点的引用，形成FIFO队列结构。
加入队列后的线程通过方法进入阻塞状态，释放CPU资源。

锁的公平性保证： 可以根据需要实现公平锁或非公平锁。 公平锁遵循先来后到的原则，每次释放锁时都会唤醒等待队列中的第一个线程；而非公平锁则可能直接尝试获取锁，即使有其他线程已经在等待。

锁的释放与唤醒机制： 当持有锁的线程完成取款操作后，它会在finally块中调用release()方法释放锁。release()方法会执行tryRelease()逻辑，将同步状态设置回0，表示锁被释放。 之后AQS会检查等待队列找到合适的线程，并唤醒该线程，使其能够重新竞争锁并执行取款操作。

在实际应用中，用户线程并不是无限期地等待，而是设定一个合理的时间限制。通过AQS所支持的获取锁时设置超时时间或者对线程进行中断处理进行设置限制。

二、锁的公平性

在AQS中，公平性和非公平性锁的实现主要体现在获取锁的策略上。

一般情况下，公平锁可以减少线程饥饿的可能性，但可能会降低系统的整体吞吐量；非公平锁虽然可能导致线程饥饿，但在许多场景下可以获得更好的并发性能。

公平锁

公平锁保证了线程请求锁的顺序与它们进入同步队列的顺序一致。在AQS中，公平锁的实现通常会在tryAcquire()方法中检查等待队列是否有其他线程正在排队等待。如果有，则当前线程不会尝试获取锁，而是直接返回失败；只有当等待队列为空时，才会尝试获取锁并修改同步状态。

hasQueuedPredecessors()用于检查是否存在已经在等待队列中的前驱节点，即是否有其他线程在等待。

protected boolean tryAcquire(int arg) {
    if (hasQueuedPredecessors() || !compareAndSetState(0, 1)) {
        return false;
    }
    setExclusiveOwnerThread(Thread.currentThread());
    return true;
}

非公平锁

非公平锁则不考虑线程等待的先后顺序，在有机会获取锁的时候就会立即尝试获取。

在下面实现中只要同步状态为0且能够成功通过CAS设置为1，那么线程就可以获取到锁，而不管等待队列的状态如何。

protected boolean tryAcquire(int arg) {
    if (getState() == 0 && compareAndSetState(0, 1)) {
        setExclusiveOwnerThread(Thread.currentThread());
        return true;
    }
    return false;
}

三、容器实现

ReentrantLock（可重入锁）： ReentrantLock 是一个可重入锁，提供了公平锁和非公平锁两种模式。通过继承自AQS并实现其模板方法，它能够支持锁的获取、释放以及线程阻塞与唤醒等功能。

Semaphore（信号量）： Semaphore 用于控制同时访问特定资源的线程数量。在AQS基础上，Semaphore管理着一组许可证，每个acquire()操作都会尝试减少许可证数量，若不足则阻塞线程；每个release()操作则会增加许可证数量并可能唤醒等待的线程。

CountDownLatch（闭锁）： CountDownLatch 允许一个或多个线程等待其他线程完成一组操作后再继续执行。它有一个计数器，通过countDown()方法递减，当计数器达到0时，所有因调用await()而被阻塞的线程都将被唤醒继续执行。AQS在这里负责管理阻塞的线程，并在计数器变化时调整线程状态。

CyclicBarrier（循环屏障）： CyclicBarrier 可以让一组线程在某个屏障点上互相等待，直到所有线程都到达这个点后才能继续执行。当最后一个线程调用await()时，所有在此之前的等待线程将被唤醒。AQS负责管理等待线程队列，并在条件满足时释放所有等待线程。

ReadWriteLock（读写锁）： ReentrantReadWriteLock是一个实现了读写分离锁的接口，内部包含两个锁：读锁和写锁。读锁可以被多个线程同时持有，而写锁在同一时间内只能被一个线程持有，这样既保证了数据一致性又提高了读取操作的并发性能。