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免费学习笔记(深入)”;
- 返回值为 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。










