排查 synchronized 线程挂起需定位“谁在等锁、谁持有锁、锁在哪”；用 jstack -l 抓取堆栈识别 BLOCKED 线程及锁地址，结合 JConsole/VisualVM 查看锁状态与死锁，优化锁粒度、避免锁内耗时操作。
排查 synchronized 引起的线程挂起等待，核心是定位「谁在等锁、谁持有锁、锁在哪」。Java 提供了多套成熟工具链，结合线程快照和锁状态分析即可快速定位。
用 jstack 抓取线程堆栈，识别 BLOCKED 线程
jstack 是最直接的手段。运行中执行：jstack -l <pid> > thread_dump.txt
重点关注状态为 BLOCKED 的线程，它们会明确标出：
- 正在等待哪个对象锁（例如：- waiting to lock <0x0000000712345678> (a java.lang.Object)）
- 持有该锁的线程（例如：- locked <0x0000000712345678> (a java.lang.Object)）
常见模式：
- 多个线程都
waiting to lock同一个地址 → 存在热点锁竞争 - 某个线程长期
locked且无后续执行痕迹（如卡在 I/O、死循环、未响应的远程调用）→ 持锁方异常阻塞
用 JConsole 或 VisualVM 实时观察线程与锁
图形化工具更直观：
- 打开「Threads」页签，筛选状态为 Blocked 的线程，点击可查看其堆栈和等待的锁对象
- 「Deadlock Detection」按钮可一键检测死锁（含 synchronized 嵌套导致的循环等待）
- 勾选「Show locked synchronizers」可显示每个线程持有的锁（包括 synchronized 锁对应的 monitor）
注意：VisualVM 需安装「Thread Inspector」插件才能完整显示锁持有关系。
立即学习“Java免费学习笔记（深入）”；
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
检查 synchronized 锁对象是否合理
很多挂起问题源于锁粒度或锁对象设计不当：
- 锁了
this或Class.class，但实际只需保护局部变量 → 改为私有 final 对象锁 - 锁了共享集合（如 static HashMap），但只读操作也加锁 → 考虑用
ConcurrentHashMap或读写锁 - 在 synchronized 块内执行耗时操作（DB 查询、HTTP 调用、sleep）→ 必须拆出锁外
示例错误写法：
synchronized(this) {
String result = httpClient.get("https://api.example.com"); // ❌ 网络调用不应在锁内
cache.put(key, result);
}
补充：用 JVM 参数辅助诊断
启动时添加参数，让 JVM 在发生死锁时自动输出信息：
-
-XX:+PrintConcurrentLocks：打印 java.util.concurrent 显式锁，对 synchronized 无效，但可排除混淆 -
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0（仅 JDK 8 及以前）：便于验证偏向锁是否被撤销引发竞争 - 更推荐配合
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log记录 VM 层锁事件（需谨慎，日志量大）
生产环境建议优先使用 jstack 定期采样（如每 5 秒一次，持续 1 分钟），比实时监控更轻量、更可靠。
