AQS中断处理：acquireInterruptibly与parkAndCheckInterrupt详解

本文深入剖析了Java并发包中AQS（抽象队列同步器）中断处理的核心机制，聚焦于acquireInterruptibly与parkAndCheckInterrupt两个关键方法如何协同实现精准、可靠的中断响应：前者在入队前即检查并消费中断标志，确保“立即响应”的语义；后者在挂起唤醒后瞬时捕获并清除中断状态，避免残留干扰后续流程。文章不仅厘清了Thread.interrupted()与isInterrupted()的本质区别、中断标志被意外清空的典型陷阱，还揭示了unpark与interrupt竞态下parkAndCheckInterrupt返回false的底层原因——中断信号仅在park返回那一刻具有确定意义，不可跨步骤依赖。对于任何使用或扩展AQS的开发者而言，这是一份直击痛点、规避高危误区的实战指南。

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 流程中。

• 返回值为 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。

到这里，我们也就讲完了《AQS中断处理：acquireInterruptibly与parkAndCheckInterrupt详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！