怎么看synchronized对应的字节码指令
Java里synchronized块或方法在编译后不会留下“synchronized”字样，而是转成monitorenter和monitorexit两条JVM指令。直接看源码看不出锁行为，必须用javap -v反编译。
- 对类文件执行
javap -v MyClass.class | grep -A 5 -B 5 monitor，能快速定位到monitorenter/monitorexit所在行 - 注意：普通
synchronized方法会在方法属性里标ACC_SYNCHRONIZED，但底层仍等价于方法体首尾加monitorenter/monitorexit - 如果看到多个
monitorexit（比如异常路径和正常路径各一个），说明JVM已自动插入了异常安全的解锁逻辑
为什么字节码里看不到偏向锁/轻量级锁/重量级锁切换
锁升级是JVM运行时行为，字节码只负责“请求锁”和“释放锁”，不参与策略决策。所有monitorenter指令在字节码层面完全一样，升级发生在HotSpot的ObjectMonitor实现中，由C++代码控制。
- 偏向锁是否启用取决于JVM参数：
-XX:+UseBiasedLocking（JDK15默认禁用，JDK8默认开启） - 锁对象头的Mark Word内容在运行时动态变化，只能用
jol（Java Object Layout）工具打印，比如ClassLayout.parseInstance(obj).toPrintable() - 不要试图从字节码推断当前锁状态——它根本没记录；你看到的只是“我要上锁”，不是“我现在用什么锁”
如何验证锁升级过程（非字节码手段）
真正观察锁升级，得靠JVM内部日志+对象头快照，而不是读字节码。字节码是静态契约，锁升级是动态优化。
- 加JVM参数：
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=vm.log，配合-XX:+TraceClassLoading可捕获部分锁膨胀事件 - 更直接的方式：用
jstack -l <pid></pid>查看线程堆栈，如果看到- locked (a java.lang.Object)后面跟着(a java.lang.Object) (biased)或(inflated)，说明当前锁状态已被JVM标记 - 注意：
Unsafe.monitorEnter()和monitorenter语义一致，但前者绕过编译器检查，无法被javap识别——别拿它测试字节码分析流程
常见误判：把wait/notify当成锁升级证据
Object.wait()会触发monitorexit + 挂起线程，但唤醒后重新进入需要再次monitorenter。这不是锁升级，只是线程调度协作。
立即学习“Java免费学习笔记（深入）”；
- 看到
wait调用后线程状态变成WAITING，不代表锁变重了；它可能仍是偏向锁，只是线程让出了CPU -
notifyAll()本身不改变锁状态，但它可能唤醒多个竞争者，从而诱发锁膨胀（比如多个线程同时尝试monitorenter失败，触发升级） - 真正触发升级的典型场景是：一个线程持有锁，其他线程反复自旋失败（轻量级锁）、再失败（偏向锁撤销）、最终升级为重量级锁——这个过程不会反映在字节码里，只在
ObjectMonitor::enter的C++路径中发生
锁升级细节藏在HotSpot的C++代码里，字节码只是入口协议。想靠javap看出锁是不是“已经膨胀”，相当于想从函数调用指令里看出内联是否发生——指令没变，执行路径早变了。
