acquireInterruptibly在阻塞前检查中断状态是因为其语义要求立即响应中断：若调用时中断标志为true，则直接抛出InterruptedException，不入队；它调用Thread.interrupted()（会清除标志），故中断仅在入口处有效。
acquireInterruptibly 为什么会在阻塞前检查中断状态
因为 acquireInterruptibly 的语义是「可响应中断地获取锁」，它必须在进入等待队列前就尊重线程的中断请求。如果线程在调用时已处于中断状态（Thread.interrupted() 返回 true），它不会尝试入队或挂起，而是直接抛出 InterruptedException。
常见错误现象：自己手动调用 thread.interrupt() 后，发现 acquireInterruptibly 没反应——大概率是调用前线程中断状态已被其他代码清空（比如之前捕获过 InterruptedException 但没重设）。
- 该方法内部调用
Thread.interrupted()，这是个带清除语义的静态方法，会把当前线程的中断标志置为 false - 只有中断发生在
acquireInterruptibly刚进入时才有效；一旦开始排队、挂起，后续中断由 AQS 自己通过parkAndCheckInterrupt()处理 - 不建议在调用前自行用
isInterrupted()判断并“预处理”，因为那无法触发清除逻辑，可能导致重复抛异常或漏响应
parkAndCheckInterrupt 怎么判断并清除中断标志
parkAndCheckInterrupt() 是 AQS 内部挂起线程并检查中断的核心辅助方法。它先调用 LockSupport.park(this)，等被唤醒后立刻执行 Thread.interrupted() ——注意，这个调用既返回当前中断状态，又把它清零。
使用场景：当线程在同步队列中被 park 挂起后，被 unpark 或中断唤醒，此时需要知道「这次唤醒是不是因为中断」，同时确保中断状态不残留到下一次 acquire 流程中。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 返回值为 true 表示本次唤醒源于中断，AQS 会向上抛出
InterruptedException - 返回值为 false 不代表没中断过，只是唤醒时中断标志已被清空（比如之前被别的代码消费过）
- 它不负责“恢复”中断状态，也不保存上下文；中断只在此刻被识别并清除，之后就没了
中断标志被清两次的典型坑：interrupted() 被误用
很多人在自定义同步器里照搬 AQS 写法，但在非 AQS 上下文中反复调用 Thread.interrupted()，结果中断信号悄无声息地消失。
常见错误现象：线程明明被中断了，但 catch (InterruptedException e) 始终没触发，或者 isInterrupted() 查不到状态——往往是因为某处多调了一次 Thread.interrupted()，把标志清掉了。
- AQS 中只在两个地方安全使用
Thread.interrupted()：入口的acquireInterruptibly和唤醒后的parkAndCheckInterrupt - 不要在
tryAcquire或tryRelease等钩子方法里主动调用它，除非你明确知道自己在消费中断 - 如果想“只查不改”，必须用
Thread.currentThread().isInterrupted()，它不改变状态
为什么 unpark + interrupt 组合可能让 parkAndCheckInterrupt 返回 false
当一个线程正在执行 LockSupport.park() 时，如果同时发生 LockSupport.unpark(t) 和 t.interrupt()，JVM 不保证二者顺序，而 park() 的语义是：只要收到 unpark 或 interrupt 就立即返回。一旦先被 unpark 唤醒，中断标志可能还没来得及生效；再执行 Thread.interrupted() 就拿不到 true。
性能影响：这不是 bug，是 JVM 对 park/unpark/interrupt 的宽松契约。AQS 接受这种不确定性，并把责任交给上层——如果你依赖精确的中断感知，就得在 acquire 成功后手动检查 Thread.currentThread().isInterrupted()。
- 该现象在高并发争抢+频繁中断场景下更明显
-
parkAndCheckInterrupt的返回值不能作为“是否曾被中断”的全局依据，仅表示“此次 park 是否因中断返回” - 别试图靠重试或轮询绕过，这会破坏 AQS 的等待队列语义
中断标志的生命周期极短，且只在 park 返回那一瞬间有确定意义；想跨步骤传递中断意图，得靠额外变量或状态机，而不是依赖线程自带的 flag。
