Mark Word 是对象头中8字节的动态位域区域，不占独立字段空间但真实存在于对象内存中；它随锁状态、GC年龄等动态复用同一块内存，本质是CPU缓存行友好的运行时状态寄存器。
Mark Word 是什么，它真在对象内存里“占地方”吗
Mark Word 不是独立字段，而是对象头（Object Header）里一块动态复用的内存区域，大小固定为 8 字节（64 位 JVM，默认开启压缩指针时）。它不存储 Java 层可见的字段，但承载了锁状态、GC 分代年龄、哈希码、偏向线程 ID 等元信息——这些内容会根据对象生命周期动态覆盖同一块内存。
关键点在于：它不是结构体，没有字段名；它是位域（bit field）布局，不同锁状态下各比特位含义完全不同。比如轻量级锁时，高 62 位存指向栈中 Lock Record 的指针；偏向锁时，低 2 位为 01，紧接着存线程 ID；无锁状态时，可能存 hashCode 或分代年龄。
- 别试图用
Unsafe.objectFieldOffset()去“定位”Mark Word——它没有 Java 层字段名，objectFieldOffset查不到 - JVM 参数
-XX:+PrintJNISupportedTypes或-XX:+PrintAssembly也看不到 Mark Word 布局，得靠源码或 hsdis 反汇编 hotspot/src/share/vm/oops/markOop.hpp - 32 位 JVM 或关闭压缩指针（
-XX:-UseCompressedOops）时，对象头整体变大，Mark Word 仍为 8 字节，但对象起始地址对齐方式变化，会影响实际偏移
锁标志位（lock bits）具体在哪几位，怎么判断当前锁状态
锁状态由 Mark Word 最低 2–3 位决定，具体看 JVM 版本和是否启用偏向锁。主流 JDK 8u 之后默认开启偏向锁，最低 2 位是锁标志位：01 表示无锁/偏向锁，00 表示轻量级锁，10 表示重量级锁，11 表示 GC 标志（如 CMS 的 mark-sweep 阶段）。
注意：仅看这 2 位不够——必须结合高位内容交叉验证。例如 01 时，若第 3 位（偏向锁启用位）为 1 且后续有线程 ID，则是偏向锁；若全零，则是普通无锁状态。
- 不要硬编码位掩码去解析，比如写
(mark & 0x3) == 0x1判断偏向锁——JVM 内部逻辑还依赖BiasedLocking::enabled()运行时开关 -
java.lang.management.ThreadMXBean#findDeadlockedThreads()或 jstack 输出里的- locked <0x...>地址，就是重量级锁时 Mark Word 中存储的ObjectMonitor*指针值（需用 jol 或 JHSDB 解析） - 使用
jol-cli.jar查看对象布局：java -jar jol-cli.jar internals java.lang.Object，输出中的mark:行就是当前 Mark Word 十六进制值，可手动对照 hotspot 源码 bit 定义
为什么用 jol 看到的 mark 值和加锁后不一样，但对象地址没变
因为 Mark Word 是对象头的一部分，而对象头与实例数据紧邻存储在堆上。对象分配后内存地址固定，但 Mark Word 内容随同步操作实时修改——它不是不可变元数据，而是运行时状态寄存器。
常见现象：新建对象用 jol 查 mark 是 0x0000000000000001（无锁+未计算 hashCode），调用 obj.hashCode() 后变成 0x0000000000000001（同值，但此时已固化 hashCode）；执行 synchronized(obj) 后，轻量锁状态下 mark 变成类似 0x00007f8b0c00a7e0（高位是栈上 Lock Record 地址）。
- 别以为 “对象没动，mark 就不该变”——恰恰相反，mark 变才是正常，不变反而说明锁没生效（比如 synchronized 块被 JIT 优化掉，或锁粗化合并）
- 使用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly观察同步指令时，会看到cmpxchg直接操作对象头起始地址（即对象引用值本身），而非某个字段偏移 - 如果用
Unsafe.compareAndSwapLong(obj, offset, expected, updated)手动改 mark，极大概率失败：不仅因并发竞争，更因 JVM 在安全点会校验 mark 合法性，非法值触发 assert 或直接 crash
偏向锁撤销和升级过程如何改写 Mark Word，哪些操作会触发它
偏向锁撤销不是“清空”，而是原子地将 Mark Word 从偏向状态（含线程 ID + epoch）替换成无锁状态（0x0000000000000005 这类带分代年龄的值），并唤醒等待线程。升级则分两步：先膨胀为轻量级锁（写入指向栈中 Lock Record 的指针），再竞争失败后升级为重量级锁（写入指向堆中 ObjectMonitor 的指针）。
触发撤销的典型场景：其他线程尝试获取已偏向的锁、调用 wait()/notify()、调用 hashCode()（若尚未计算）、发生批量重偏向阈值超限（-XX:BiasedLockingBulkRebiasThreshold）。
-
System.identityHashCode(obj)和obj.hashCode()效果不同：后者可能触发偏向撤销（若对象已偏向且未缓存 hash），前者强制计算并写入 mark，但不会撤销偏向（JDK 8u292+ 修复） - 禁用偏向锁（
-XX:-UseBiasedLocking）后，mark 最低 2 位直接从01变成00，跳过偏向阶段，所有锁都从轻量级开始 - GC 时（尤其是 CMS 和 ZGC 的并发标记阶段）会扫描 mark word，遇到
11标志位就按 GC 对象处理——所以不要在非 GC 线程里手动把 mark 改成0x3，否则下次 GC 可能把它当垃圾回收
事情说清了就结束。Mark Word 的本质是 CPU 缓存行友好的状态寄存器，不是供你读写的字段。真正要调试它，得接受“只能看、不能碰”的前提，老实用 jol + JVM 参数 + 源码对照。
