Java中synchronized锁升级状态决定性能可观测性：偏向锁下无阻塞痕迹，轻量级锁自旋致CPU飙升但Thread.State仍为RUNNABLE，重量级锁才在jstack中显示waiting to lock及BlockedCount上升。
Java 中 synchronized 的锁升级状态直接影响性能可观测性——不是锁本身变慢了，而是不同状态下的行为特征、日志痕迹和线程行为差异极大，若不明确当前所处状态，监控数据会严重失真甚至误导调优方向。
锁状态决定你能看到什么指标
偏向锁下几乎看不到线程阻塞，Thread.State 始终是 RUNNABLE，JVM 线程 dump 里不会出现 BLOCKED；轻量级锁阶段虽有自旋，但 CPU 使用率可能局部飙升而无明显阻塞记录；一旦升级为重量级锁，线程 dump 中大量线程卡在 java.lang.Object.wait(Native Method) 或 parking to wait for，BlockedCount 和 WaitedCount 显著上升。
- 用
jstack <pid>查看时，只有重量级锁才会显示- waiting to lock <0x...> -
jstat -gc <pid>无法反映锁状态，但频繁的 safepoint 停顿（如PrintSafepointStatistics输出）往往对应偏向锁撤销 - JFR（Java Flight Recorder）中，
jdk.JavaMonitorEnter事件在轻量级锁阶段触发频繁，在重量级锁阶段则伴随明显延迟字段
日志开关必须匹配目标状态
想观测锁升级过程，光加 -XX:+PrintGC 没用。关键参数需按目标状态组合启用：
- 查偏向锁建立与撤销：
-XX:+TraceBiasedLocking -XX:+UnlockDiagnosticVMOptions - 确认是否发生撤销停顿：
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 - 对比有无偏向锁的影响：
-XX:-UseBiasedLocking（禁用后所有锁从轻量级起步） - 观察对象头变化：
-XX:+PrintStringTableStatistics配合ClassLayout.parseInstance(obj).toPrintable()
常见误判场景及识别要点
很多“性能差”问题被归因为 synchronized，实际是锁状态误判导致：
立即学习“Java免费学习笔记（深入）”；
-
以为没竞争，实则已升级：单线程反复执行同步块，本该走偏向锁，但若此前调用过
hashCode()或wait()，对象头已被破坏，直接跳过偏向锁进入轻量级 -
把自旋当空转：轻量级锁阶段线程处于
RUNNABLE状态，top -H显示高 CPU，容易误判为死循环，实则是 CAS 自旋争抢锁 - 忽略安全点开销：偏向锁撤销必须进入 safepoint，若应用本身 GC 频繁或存在长耗时 JNI 调用，撤销过程会被延迟放大，表现为偶发性毛刺而非持续瓶颈
生产环境建议的轻量观测组合
无需开启全量诊断日志也能掌握关键线索：
- 定期采集
jstack，搜索waiting to lock出现频次和锁地址分布 - 用
jcmd <pid> VM.native_memory summary辅助判断是否大量分配 mutex 内存（重量级锁特征） - 结合
arthas watch监控synchronized方法进入/退出耗时，突增延迟大概率发生在锁升级临界点 - 对高频同步对象，用
Unsafe.objectFieldOffset+Unsafe.getInt读取 Mark Word 低 3 位，实时判断锁标志位（001/101/00/10）
