AQS在中断时仅将节点设为CANCELLED并逻辑跳过，不释放锁、不修改state，仅清理等待队列；唤醒时自动绕过取消节点，需上层主动抛出InterruptedException。
当线程在 doAcquireInterruptibly 中因中断而退出等待时，AQS 会主动清理该线程对应的节点（Node），并确保锁状态不受干扰——它不释放锁，只取消自身等待资格，避免残留节点影响后续同步逻辑。
中断发生时节点被标记为 CANCELLED
线程被中断后，AQS 不会直接 unpark 其他节点或修改 state，而是将当前线程对应的 Node 的 waitStatus 设为 CANCELLED（值为 1）。这个标记是清理的起点，表示该节点已失效，不应再参与唤醒链路。
- 节点进入等待队列后，若检测到中断（
Thread.interrupted()返回 true），立即调用cancelAcquire(node) -
cancelAcquire会先将 node.waitStatus = CANCELLED - 接着跳过所有前驱中 waitStatus == CANCELLED 的节点，尝试用 CAS 更新前驱的 next 指针，将其指向 node 的后继
- 若前驱已取消或更新失败，还会触发一次唤醒后继的“清理传播”（通过
unparkSuccessor）
不改变锁的持有状态
该方法仅处理“获取失败”的场景，与锁是否已被其他线程持有无关。即使当前 state > 0（锁已被占），中断也只导致当前请求线程放弃排队，不会触发 release 或 state 减法操作。
- state 的变更只发生在
tryAcquire成功时（由子类实现），中断路径全程不调用tryRelease - 因此，中断清理是纯队列层面的操作，不影响临界区语义和重入计数
- 如果线程在 acquire 前已持锁（如可重入场景），中断也不会破坏其 ownHoldCount
后续唤醒链路自动绕过已取消节点
AQS 的唤醒机制（如 unparkSuccessor）在查找下一个有效后继时，会跳过所有 waitStatus == CANCELLED 的节点。这意味着清理不是即时物理删除，而是通过“逻辑隔离 + 惰性跳过”保证队列一致性。
- 当 head 变更或某节点被 unpark 后，它的后继若为 CANCELLED，会继续向后扫描直到找到第一个非取消节点
- 这种设计避免了并发修改队列时的复杂同步，也降低了 cancel 操作的开销
- 极端情况下，大量取消节点可能堆积，但 AQS 在
enq和shouldParkAfterFailedAcquire中也会做轻量级清理
用户需配合抛出 InterruptedException
doAcquireInterruptibly 自身不抛异常，它把中断信号传递给上层：调用方必须检查 Thread.interrupted() 并主动 throw，否则中断状态丢失，且无法体现业务意图。
- 典型模式：
if (Thread.interrupted()) throw new InterruptedException();放在循环外或 acquire 失败分支 - 如果不抛异常，线程虽退出等待，但调用栈无法感知中断，可能掩盖超时/取消逻辑
- 子类实现
tryAcquire时也应保持响应性，避免在其中忽略中断
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
