synchronized锁升级不改变Java对象内存布局，仅复用Mark Word位字段重新解释锁状态。对象头、实例数据、对齐填充三部分结构恒定，大小与偏移不变；hashCode获取路径和Monitor创建有运行时影响，但对象自身布局无任何变更。
synchronized锁升级本身不改变Java对象的内存布局结构，也不会增加对象在堆中占用的空间大小。
对象在JVM堆中的布局始终由三部分组成：对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。锁升级只影响对象头中 Mark Word 的内容解释方式，不新增字段、不调整字段顺序、不改变Klass Pointer位置，也不影响实例字段的排布或对齐规则。
锁升级只复用Mark Word，不改动内存结构
Mark Word是一块固定大小的内存区域（64位JVM下为8字节，32位JVM下为4字节），它不是“额外分配”的空间，而是被设计为多用途复用字段。不同锁状态下，JVM只是重新解释这同一块内存里各比特位的含义：
- 无锁时：存hashCode（25位）、分代年龄（4位）、偏向标志（1位）、锁标识（2位）等
- 偏向锁时：腾出hashCode位置，存线程ID（54位）和epoch（2位），锁标识仍为
01，但偏向位设为1 - 轻量级锁时：整个Mark Word写入指向当前线程栈中Lock Record的指针（62位），锁标识变为
00 - 重量级锁时：该指针替换为指向堆中ObjectMonitor对象的地址，锁标识变为
10
这些切换全程发生在同一块Mark Word内存内，对象头总长度、实例数据起始地址、对齐填充需求均保持不变。
立即学习“Java免费学习笔记（深入）”；
不影响对象大小，但间接影响GC与哈希行为
虽然对象体积没变，但Mark Word内容变化会带来两个运行时层面的副作用：
-
hashCode迁移：进入偏向锁后，原始hashCode被移出Mark Word，后续调用
System.identityHashCode()会从Monitor中读取；若从未计算过，则首次调用才生成并缓存 - GC分代年龄共存：无论锁状态如何，GC年龄字段始终保留在Mark Word中（通常占4位），与锁标识、偏向位等共享同一字段，不会因锁升级而丢失或重置
这意味着：
- 对象序列化、内存dump分析时看到的对象大小恒定
-
ObjectLayout.parseInstance(obj)输出的内存布局图在锁升级前后完全一致 - 但通过JOL（Java Object Layout）观察Mark Word值，会发现其十六进制内容随锁状态明显变化
JVM位宽决定字段容量，不影响布局逻辑
32位与64位JVM下Mark Word总长度不同，导致各锁状态可存储的信息量有差异：
- 32位JVM：Mark Word仅32 bit → 线程ID最多23位，Lock Record/Monitor指针限30位
- 64位JVM（默认开启压缩指针）：Mark Word仍为64 bit，Class Pointer压至32位，多出32位全用于锁字段 → 线程ID扩展到54位，指针达62位
但这种差异是位宽约束下的自然结果，不是布局结构调整。对象头整体结构（Mark Word + Klass Pointer + 数组长度）依然严格遵循规范，对齐填充规则也完全不变。
总结：锁升级是语义切换，不是结构变更
- ✅ 对象头大小不变、实例数据偏移不变、对齐填充策略不变
- ✅ 不新增任何字段，不修改类元数据，不触发对象重分配
- ⚠️ hashCode获取路径可能延迟或迁移，Monitor对象会在堆中独立创建（但属于全局复用结构，不绑定单个对象生命周期）
- ⚠️ 多线程竞争下Monitor对象的创建和销毁会有少量堆内存开销，但这与对象自身布局无关
本质上，锁升级是一套基于Mark Word位字段的动态语义协议，目标是减少同步开销，而非改变内存形态。
