ReentrantLock 通过 lockInterruptibly() 实现锁中断，基于 AQS 在等待队列中响应 interrupt 并抛出 InterruptedException；中断仅作用于未获锁的阻塞线程，不影响持锁线程；synchronized 不支持中断，而 lockInterruptibly() 是唯一标准可中断锁获取方式。
ReentrantLock 实现锁中断的核心在于 lockInterruptibly() 方法，它让线程在等待锁时能响应 Thread.interrupt() 信号，主动退出阻塞，而不是无限期等待。
基于 AQS 的可中断等待队列
ReentrantLock 底层依赖 AbstractQueuedSynchronizer（AQS）。当线程调用 lockInterruptibly() 而锁不可用时，AQS 会将该线程封装为 Node 加入同步等待队列，并调用 LockSupport.park() 使其进入 WAITING 状态。此时线程完全放弃 CPU，不消耗资源。
- 与
lock()不同，lockInterruptibly()在入队后使用的是acquireInterruptibly()流程，该流程在每次 park 前/后都会检查线程中断状态 - AQS 内部不屏蔽中断；一旦线程被 interrupt，JVM 会唤醒它并将其状态设为 RUNNABLE
- 线程恢复执行后，AQS 立即检测到中断标志为 true，不再重试获取锁，而是直接抛出
InterruptedException
中断只作用于“等待中”的线程，不影响持有者
锁中断机制有明确边界：它只对尚未获得锁、正在队列中阻塞的线程生效。已成功持有锁的线程，无论是否被中断，其执行不受影响，也不会被强制释放锁。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 这保证了锁的互斥性和临界区安全性——中断不能破坏正在运行的业务逻辑
- 若误以为中断能“踢出”持锁线程，会导致对锁行为的错误设计
- 典型误用：在持锁线程中调用
Thread.currentThread().interrupt()，对锁本身无任何作用
与 synchronized 的本质区别
synchronized 是 JVM 层原语，其等待逻辑固化在字节码和解释器中，无法插入中断检查点；而 ReentrantLock 是 Java 层实现，所有锁操作都走可定制的 AQS 框架，因此能在 park/unpark 节点精准嵌入中断判断。
立即学习“Java免费学习笔记（深入）”；
-
synchronized下，即使线程被 interrupt，仍卡在 Blocked 状态，直到锁释放 -
ReentrantLock.lock()表现类似，也不响应中断 - 只有
lockInterruptibly()显式启用中断路径，是唯一标准的可中断锁获取方式
实际使用的关键约束
要使锁中断真正生效，必须满足两个前提条件：
- 调用方必须声明或捕获
InterruptedException，否则编译不通过 - 不能在 catch 块中简单吞掉异常后继续尝试加锁，否则失去中断意义；应清理资源、退出任务或转交处理
- 公平锁与非公平锁均支持
lockInterruptibly()，中断行为一致，区别仅在于排队策略
