reentrantlock 的等待中断处理由 aqs 主动检查线程中断状态实现：第一道检查在入队前，已中断则快速失败；第二道在 park 返回后循环中检测并清理中断标志，确保异常抛出前节点已移除；全程使用 thread.interrupted() 清除并消费中断信号，公平与非公平锁机制一致。
ReentrantLock 的等待中断处理，本质是 AQS 通过 可中断的独占获取逻辑 实现的——它不依赖底层线程阻塞的“自动响应中断”，而是由 AQS 主动检查线程中断状态，并在关键节点抛出 InterruptedException，从而让上层锁操作（如 lockInterruptibly()）具备响应性。
中断发生在等待队列入队前
调用 lockInterruptibly() 时，AQS 先尝试非阻塞获取锁（tryAcquire）。失败后进入 acquireInterruptibly 流程，此时会先检查当前线程是否已中断（Thread.interrupted()），若已中断则直接抛出异常，避免构造 Node、加入同步队列等开销。
- 这是第一道中断检查，属于“快速失败”路径
- 不会创建节点，也不修改队列结构，安全且轻量
中断发生在阻塞等待中
线程成功入队后调用 park 进入阻塞。JVM 的 LockSupport.park() 在被中断时会立即返回（但不清除中断标志）。AQS 的 acquireQueued 方法在每次循环中都会检查：当前线程是否被中断，以及该次 park 是否因中断而提前唤醒。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 若检测到中断（且尚未被其他线程设置过
interrupted状态），AQS 会主动抛出InterruptedException - 注意：抛异常前会确保当前节点已从队列中移除（或标记为取消），避免残留脏节点
- 这个检查发生在 park 返回后的循环头部，保证不漏判
中断状态的清理与传递
AQS 不直接保留线程的中断状态，而是通过 Thread.interrupted() 获取并清除中断标志，再由上层方法（如 ReentrantLock.lockInterruptibly）重新抛出异常。这样既符合 Java 中断语义（中断是一次性信号），又避免干扰其他可能依赖中断逻辑的代码。
- 每次检查都调用
Thread.interrupted()，而非isInterrupted()，确保中断标志被消费 - 异常抛出后，线程的中断状态已被清除，调用方如需继续传播，需手动重置（如
Thread.currentThread().interrupt()）
公平锁与非公平锁在此机制中行为一致
无论是公平还是非公平模式，中断检查的时机和逻辑完全相同。区别仅在于获取锁时是否严格遵循 FIFO 顺序，而中断响应本身由 AQS 统一控制，与公平性无关。
- 非公平锁的“插队”尝试（即
tryAcquire）同样受中断检查约束 - 一旦进入排队流程，后续所有中断判断均由 AQS 负责，与锁实现方式解耦
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
