Java对象头的Mark Word动态决定synchronized锁行为：无锁（01，存哈希码）、偏向锁（01但biased=1，存线程ID）、轻量级锁（00，存栈中Lock Record指针）、重量级锁（10，存ObjectMonitor指针），升级由线程竞争触发且不可逆。
Java对象头直接决定synchronized锁的行为，而变量竞争会强制改变对象头中Mark Word的结构，从而触发锁升级。关键不在“有没有加锁”，而在“有多少线程在争这个对象”。
对象头是锁状态的实时快照
每个Java对象在堆中都有一个对象头，其中Mark Word字段动态存储锁信息。它不是固定结构，而是随竞争情况实时切换内容：
- 无锁时：存哈希码、GC年龄，标志位为01
- 偏向锁时：存线程ID、epoch、年龄，标志位仍为01（但biased_lock=1）
- 轻量级锁时：存指向栈中Lock Record的指针，标志位变为00
- 重量级锁时：存指向堆中ObjectMonitor的指针，标志位变为10
这些变化全由JVM在运行时自动完成，不需要开发者干预，但必须理解——对象头不是配置项，是竞争结果的客观记录。
变量竞争如何推动锁升级
所谓“变量竞争”，本质是多个线程反复尝试对同一对象执行synchronized操作。这种行为会逐级打破低开销锁的假设条件：
立即学习“Java免费学习笔记（深入）”；
- 第一次访问：单线程进入，JVM启用偏向锁，在Mark Word写入线程ID
- 第二个线程尝试进入：检测到非本线程ID，触发偏向撤销（需安全点暂停），升级为轻量级锁
- 若此时第三个线程也来争，或前两个线程频繁交替进入：自旋失败超阈值（默认10次），立即膨胀为重量级锁
- 一旦升级为重量级锁，后续所有竞争都走操作系统Mutex流程，用户态→内核态切换开销固定存在
注意：hashCode调用也会干扰——只要调用obj.hashCode()或System.identityHashCode(obj)，JVM必须把hash值写进Mark Word，导致空间冲突，永久禁用偏向锁。
热点对象会让锁升级失效
当某个对象（如共享计数器、单例配置管理器）被大量线程高频访问，它就成为“热点对象”。此时即使逻辑上只有读操作，只要同步块存在，竞争就真实发生：
- 轻量级锁的自旋会耗尽CPU周期，尤其在多核高负载下
- 重量级锁使线程排队阻塞，引发上下文切换风暴
- JVM无法降级，锁状态只能单向升级，该对象从此长期处于高开销锁模式
典型表现是应用吞吐下降、GC日志中出现大量线程停顿（Stop-The-World间接加剧），但CPU使用率可能不低——因为很多时间花在了自旋和系统调用上。
怎么判断是否被竞争影响了
不能只看代码写了synchronized，要观察运行时对象头的真实状态：
- 用JOL（Java Object Layout）工具打印对象头，对比不同阶段Mark Word的十六进制值
- 开启JVM参数
-XX:+PrintSynchronizationStatistics -XX:+UnlockDiagnosticVMOptions，查看锁统计 - 通过Arthas的
monitor或thread -b命令，定位阻塞最久的synchronized方法 - 注意类级别锁（static方法）和实例级别锁（this）的区别：前者所有实例共用一把锁，更容易形成热点
锁升级不是bug，是JVM在资源约束下的理性选择；但过度依赖它，等于把性能决策权交给了运行时——而生产环境需要的是确定性。
