lockinterruptibly()的核心作用是防止线程在锁等待阶段无限阻塞，通过响应中断信号及时退出等待、提升系统响应性；它不改变可重入性，仅改变锁获取行为，需严格遵循try-catch-finally结构，并常与trylock配合使用。
可重入锁配合 lockInterruptibly() 的核心作用，不是直接“避免死锁”，而是防止线程在锁等待阶段无限阻塞（即“死等”），从而提升系统响应性与可控性。它让中断信号真正穿透到锁获取环节，使线程能及时退出、释放资源或转向备用逻辑。
lockInterruptibly 为什么能打破“死等”
普通 lock() 在锁不可用时会一直阻塞，即使调用 interrupt() 也完全无反应；而 lockInterruptibly() 在等待过程中一旦收到中断信号，立刻抛出 InterruptedException 并退出等待——此时线程肯定没拿到锁，也不会继续傻等。
- 中断发生时，锁一定未被当前线程持有，无需担心解锁问题
- 它不改变锁本身的可重入性，只改变“获取锁”的行为方式
- 这是
ReentrantLock唯一支持中断响应的锁获取方式
必须严格遵循的使用结构
因为 lockInterruptibly() 可能在任意阶段抛异常（还没进 try、刚进 try、临界区执行中），所以结构不能简化：
- try 块里调用
lockInterruptibly()，再执行临界区逻辑 - catch 中必须调用
Thread.currentThread().interrupt()恢复中断状态，否则上层无法感知 - finally 中用
isHeldByCurrentThread()判断是否真持有锁，再调用unlock() - 绝不能用
isLocked()替代判断——它只说明锁被谁占了，不反映当前线程状态
典型适用场景
这些地方最需要“可中断等待”能力：
- RPC 调用链中下游响应慢，上游主动中断等待，快速失败并降级
- 命令行工具或交互式服务，用户按 Ctrl+C 时优雅终止正在争抢锁的任务
- ForkJoinPool 或自定义线程池中，任务窃取（work-stealing）需限时尝试获取资源
- 分布式协调中，本地锁等待超时前被集群指令中断，避免单点卡死
和 tryLock 配合更灵活
单纯靠 lockInterruptibly() 还不够，常与 tryLock(long, TimeUnit) 组合使用：
- 先用
tryLock(100, MILLISECONDS)快速尝试，失败则进入带中断的等待流程 - 或者用
lockInterruptibly()+ 外部定时器（如 ScheduledExecutorService）主动中断等待线程 - 注意：
tryLock返回 false 不抛异常，也不影响中断状态；lockInterruptibly抛异常才表示中断真实生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
