acquireSharedInterruptibly在入队前检查中断并抛出异常，避免入队；中断唤醒后调用cancelAcquire清理节点，设waitStatus为CANCELLED，跳过传播逻辑，不执行setHeadAndPropagate。
acquireSharedInterruptibly 为什么比 acquireShared 多一次中断检查
它不是“多检查一次”，而是把中断响应提前到了入队前。如果线程在调用 acquireSharedInterruptibly 时已被中断（Thread.interrupted() 返回 true），会直接抛出 InterruptedException，根本不会走到入队逻辑。这点和 acquireInterruptibly 一致，但共享模式下后续传播唤醒的处理更复杂。
doAcquireSharedInterruptibly 中断被唤醒后如何清理节点
当线程因中断被 parkAndCheckInterrupt() 唤醒后，会进入异常路径：节点仍处于队列中，但状态未变；此时需主动取消该节点，避免干扰后续 doReleaseShared 的传播判断。
-
cancelAcquire(Node node)被调用，将节点waitStatus设为CANCELLED - 跳过所有
waitStatus > 0（即已取消）的前驱节点，重连链表 - 若该节点是 tail，还会尝试 CAS 更新 tail；若其后继是共享节点，不触发传播
- 注意：该节点不会被
setHeadAndPropagate处理，因为它永远无法成为 head
中断发生时 setHeadAndPropagate 还会执行吗
不会。一旦 interrupted == true，循环会提前退出，且 failed = true，最终进入 finally 块执行 cancelAcquire(node)。整个流程绕过了 setHeadAndPropagate 的所有逻辑——包括设置新 head、检查 propagate、调用 doReleaseShared。
这意味着：一个被中断的共享等待线程，不仅自己放弃获取，也不会参与任何唤醒传播。这是设计使然，不是 bug。
容易忽略的关键点：PROPAGATE 状态与中断的交互
PROPAGATE（-3）只在共享锁成功获取并传播时由 setHeadAndPropagate 设置，而中断路径完全不经过它。但要注意：如果中断发生在 doReleaseShared 正在执行中（比如另一个线程刚释放、正遍历后继），当前被中断线程的节点虽已 CANCELLED，却可能被 doReleaseShared 的自旋逻辑短暂读到——这时它的 next.isShared() 判断会失败（因为 next == null 或非 SHARED），不会误唤醒。真正危险的是手动修改 waitStatus 或复用已取消节点，这在标准 AQS 实现里被严格规避。
