Java 中 synchronized 锁升级状态对性能观测的影响

Ja va 中 synchronized 的锁升级状态，说白了直接影响你“看到”的性能表现——不是锁本身变慢了，而是不同状态下的行为特征、日志痕迹和线程状态差异极大。如果不明确当前处于哪个阶段，监控数据很可能严重失真，甚至把调优方向带偏。

锁状态决定你能看到什么指标

偏向锁下几乎看不到线程阻塞，Thread.State 始终是 RUNNABLE，JVM 线程 dump 里根本不会出现 BLOCKED；轻量级锁阶段虽然有自旋，但 CPU 使用率可能在局部飙升，而线程状态却没有任何阻塞记录；一旦升级为重量级锁，线程 dump 中就会出现大量线程卡在 ja va.lang.Object.wait(Native Method) 或 parking to wait for，BlockedCount 和 WaitedCount 显著上升。

• 用 jstack 查看时，只有重量级锁才会显示 - waiting to lock <0x...>
• jstat -gc 无法反映锁状态，但频繁的 safepoint 停顿（比如 PrintSafepointStatistics 输出）往往对应偏向锁撤销
• JFR（Ja va Flight Recorder）中，jdk.Ja vaMonitorEnter 事件在轻量级锁阶段触发频繁，在重量级锁阶段则伴随明显的延迟字段

日志开关必须匹配目标状态

想观测锁升级过程，光加 -XX:+PrintGC 肯定没用。关键参数需要按目标状态组合启用：

• 查偏向锁建立与撤销：-XX:+TraceBiasedLocking -XX:+UnlockDiagnosticVMOptions
• 确认是否发生撤销停顿：-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1
• 对比有无偏向锁的影响：-XX:-UseBiasedLocking（禁用后所有锁从轻量级起步）
• 观察对象头变化：-XX:+PrintStringTableStatistics 配合 ClassLayout.parseInstance(obj).toPrintable()

常见误判场景及识别要点

很多“性能差”的问题被归因为 synchronized，实际是锁状态误判导致的。以下几个场景尤其值得注意：

• 以为没竞争，实则已升级：单线程反复执行同步块，本该走偏向锁，但若此前调用过 hashCode() 或 wait()，对象头已被破坏，直接跳过偏向锁进入轻量级
• 把自旋当空转：轻量级锁阶段线程处于 RUNNABLE 状态，top -H 显示高 CPU，很容易误判为死循环，实际上是 CAS 自旋争抢锁
• 忽略安全点开销：偏向锁撤销必须进入 safepoint，如果应用本身 GC 频繁或存在长耗时 JNI 调用，撤销过程会被延迟放大，表现为偶发性毛刺而非持续瓶颈

生产环境建议的轻量观测组合

其实不需要开启全量诊断日志，也能掌握关键线索：

• 定期采集 jstack，搜索 waiting to lock 出现频次和锁地址分布
• 用 jcmd VM.native_memory summary 辅助判断是否大量分配 mutex 内存（重量级锁的特征）
• 结合 arthas watch 监控 synchronized 方法进入/退出耗时，突增延迟大概率发生在锁升级的临界点
• 对高频同步对象，可以用 Unsafe.objectFieldOffset + Unsafe.getInt 读取 Mark Word 低 3 位，实时判断锁标志位（001/101/00/10）