reentrantlock的lockinterruptibly()通过aqs在park前后主动轮询thread.interrupted()实现可中断：失败时入队，park返回后立即检查中断状态，若为true则抛interruptedexception并取消节点；而synchronized完全不响应中断。
ReentrantLock 的可中断锁（lockInterruptibly()）底层依赖 JVM 线程中断机制与 AQS（AbstractQueuedSynchronizer）的协作，核心在于：线程在阻塞等待锁时，不是通过无响应的 park()，而是调用支持中断检测的 parkNanos() 或配合 Thread.interrupted() 主动轮询，并在被中断时立即抛出 InterruptedException，从而退出等待、清理节点、恢复执行流。
中断信号如何被 AQS 捕获并响应
AQS 使用 LockSupport.park() 阻塞线程，但该方法本身**不响应中断**——它只会让线程休眠，即使被 interrupt() 也继续挂起。真正实现“可中断”的关键，在于 AQS 在 park 前后主动检查中断状态，并在 park 返回后再次确认：
- 调用
acquireQueued()前，先调用Thread.interrupted()清除并获取当前中断状态；若已中断，则直接抛异常，不入队 - 入队后在自旋 + park 循环中，每次 park 返回后都检查
Thread.interrupted()；一旦发现中断，就调用cancelAcquire()将当前节点设为CANCELLED并从同步队列中移除 - 整个过程不依赖 park 自身响应中断，而是靠“park 后立刻查中断”+“中断时主动取消排队”完成语义保证
lockInterruptibly() 的实际执行路径
以非公平锁为例，lockInterruptibly() 最终委托给 AQS 的 acquireInterruptibly(int arg) 方法，流程如下：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 先尝试快速获取锁（
tryAcquire(arg)），成功则直接返回 - 失败则构造 Node 入同步队列，进入
doAcquireInterruptibly(arg) - 该方法中：循环中调用
shouldParkAfterFailedAcquire()判断是否该 park；若该 park，则调用parkAndCheckInterrupt() -
parkAndCheckInterrupt()内部是LockSupport.park(this)+Thread.interrupted()，返回值即中断状态；若返回 true，立即抛InterruptedException
为什么 interrupt() 能及时生效，而不是等到锁释放？
因为线程并非“死等锁”，而是在 AQS 队列中以“自旋 + 条件阻塞”方式等待。park 只是优化手段，避免空转耗 CPU；但每次 park 返回（无论因 unpark 还是虚假唤醒），都会重新检查前驱节点状态和自身中断标记。这意味着：
- 中断发生在 park 中：JVM 会设置线程的中断状态，park 返回后立刻被
Thread.interrupted()捕获 - 中断发生在 park 前：下一次循环开始前就会被检查到
- 中断发生在 unpark 后、下次 park 前：同样会在进入 park 前被拦截
- 没有“必须等锁释放才能响应中断”的依赖，响应延迟仅限于一次 park/unpark 周期（通常微秒级）
与 synchronized 的中断能力对比
synchronized 关键字**完全不支持中断等待**：一旦线程阻塞在 monitor enter 上，interrupt() 只会设置中断状态，不会唤醒线程，也不会抛异常——直到它最终获得锁并进入临界区后，才能通过 Thread.interrupted() 手动感知。而 ReentrantLock 的可中断设计，本质是把锁等待逻辑从 JVM 底层 monitor 搬到了 Java 层 AQS，从而获得对等待过程的完全控制权。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
