Ubuntu上从Java日志发现线程死锁的实用步骤
一、快速判断是否有死锁
- 在应用日志或控制台中直接搜索关键字：“Found one Java-level deadlock”。出现该提示通常意味着 JVM 的线程分析已发现一组线程互相等待对方持有的锁，这是最直观的死锁信号。若日志中已有线程转储（thread dump），优先在转储末尾查找该提示及其后的线程互锁关系说明。
二、从线程转储定位死锁位置
- 获取线程转储
- 查找进程号：jps -l 或 ps -ef | grep java
- 生成快照：jstack > thread_dump.log；如需更完整信息可用 jstack -l （-l 会打印锁持有与等待关系）
- 在转储中确认死锁
- 全文搜索：“Found one Java-level deadlock”。其后会列出互相等待的线程、各自持有的锁与等待的锁，据此可直接定位到相关类与代码行号。
- 辅助识别阻塞与等待关系
- 关注线程状态与关键字：BLOCKED / waiting for monitor entry / waiting to lock / locked <0x…>。例如：
- “waiting to lock <0x…> (a java.lang.Object), which is held by “Thread-X””表示该线程在等某个对象监视器，而该监视器被 Thread-X 持有。
- 多个线程形成环形等待（A 等 B 的锁，B 等 A 的锁）即为死锁。结合堆栈中的类、方法及行号即可定位问题代码。
三、借助图形化与运行时工具
- JConsole：运行 jconsole，连接到目标进程，切到“线程”页，点击检测死锁，工具会自动分析并给出互锁线程详情。
- JVisualVM：安装 VisualVM 插件后，连接到进程，在“线程”页使用“检测死锁”功能，可视化查看线程与锁的持有/等待关系。
- Arthas（可选）：线上诊断利器，使用如 thread 等命令快速查看阻塞线程与锁信息，适合无法立即获取完整线程转储的场景。
四、日志中无显式提示时的排查与预防
- 主动采集多份线程转储对比
- 间隔 3–5 秒连续采集 2–3 份：jstack > dump1.log; sleep 5; jstack > dump2.log。对比各份中处于 BLOCKED 且互相“waiting to lock … which is held by …”的线程，识别稳定的循环等待链。
- 预防与修复要点
- 统一加锁顺序：多个锁按固定全局顺序获取，破坏“循环等待”。
- 使用超时获取：对 ReentrantLock 使用 tryLock(timeout)，超时则回退/重试，避免无限等待。
- 缩小锁粒度与锁分离：读写分离（如 ReadWriteLock）、按业务拆分锁，降低竞争。
- 确保释放：显式锁必须在 try-finally 中释放，避免异常路径漏解锁导致“永久阻塞”。