ReentrantLock死锁与阻塞主因是显式加解锁易出错，排查需通过jstack还原线程持锁/等待链，关注BLOCKED、WAITING状态及ownable synchronizer线索，并结合公平锁、审计日志、tryLock超时、JMX/Arthas监控等手段主动防控。
ReentrantLock 的死锁和线程阻塞问题，核心在于显式加锁/解锁的可控性反而放大了使用错误的风险。它不像 synchronized 那样自动释放锁，一旦忘记 unlock、异常未捕获、或 lock/unlock 不成对，就极易引发阻塞或死锁。排查关键不是“找锁”，而是“还原线程持锁与等待链”。
用 jstack 抓取线程快照，定位阻塞与循环等待
jstack 是最直接有效的手段。在疑似卡住时执行：
jstack <pid> > thread_dump.txt
重点看三类线索：
- java.lang.Thread.State: BLOCKED —— 线程在等某个 monitor（synchronized）或 AQS 队列中的锁；注意它后面紧跟着的 "waiting to lock <0x...>"，这个地址就是目标锁对象的哈希值
- java.lang.Thread.State: WAITING (parking) —— ReentrantLock 中常见状态，说明线程已进入 AQS 的同步队列，正在 park 等待被唤醒
- 搜索 "ownable synchronizer" 或 "AbstractQueuedSynchronizer$ConditionObject"，可定位到 ReentrantLock 实例；结合线程栈中 lock() / await() 调用位置，判断是否持有锁却未释放，或在条件队列中永久等待
启用 ReentrantLock 的 fairness + 审计日志，暴露隐性竞争
非公平锁（默认）会掩盖部分调度问题，开启公平模式能更早暴露争抢激烈或锁持有时间过长的情况：
立即学习“Java免费学习笔记（深入）”；
ReentrantLock lock = new ReentrantLock(true); // true 表示公平锁
但更重要的是在关键路径添加轻量级审计：
- 在 lock() 前打点记录线程 ID 和时间戳；在 unlock() 后记录释放耗时；若发现某线程 lock 后迟迟不 unlock，基本可锁定泄漏点
- 对同一把锁的多次 lock/unlock 操作，用 ThreadLocal 记录嵌套深度，防止 lock() 多次但 unlock() 不足（可导致锁无法真正释放）
- 避免在 lock 区域内做 I/O、远程调用或复杂计算——这些是阻塞延长的主因
用 tryLock() + 超时 + 回退逻辑，主动规避死锁
ReentrantLock 支持带超时的 tryLock(long, TimeUnit)，这是预防死锁最实用的编码习惯：
- 当需要按固定顺序获取多把锁时，不要简单 lock1.lock(); lock2.lock();，而应统一用 tryLock(100, MILLISECONDS)，失败则释放已持锁并重试或降级
- 若超时返回 false，说明竞争严重或已有线程长期持锁，此时可记录告警、触发 dump、或切换为读缓存等降级策略
- 配合 Thread.interrupted() 检查中断状态，在 lock 前响应中断，避免无限等待
借助 JMX 或 Arthas 动态监控锁状态
生产环境不便频繁 dump？可用标准 JMX 接口或 Arthas 快速诊断：
- JDK 自带 java.util.concurrent.locks.Lock 的 MBean（如 java.util.concurrent.locks:type=ReentrantLock,name=xxx），可查 QueueLength（等待线程数）、HasQueuedThreads、IsLocked 等指标
- Arthas 的 thread -b 命令能直接找出当前 BLOCKED 线程及其阻塞源头；watch 命令可监听 ReentrantLock.lock() 和 unlock() 的调用参数与耗时
- 对高频锁操作，可封装一个带统计的代理锁（如记录平均等待时间、失败率），接入 Prometheus 监控告警
