Mark Word的锁标志位位于对象头前8字节（64位JVM）中一个4-bit字段，与GC年龄、哈希码、偏向线程ID共用同一内存区域，通过位运算动态复用，其值需用jol工具或JVM诊断参数实时观测。
Java对象头里Mark Word的锁标志位到底存哪儿
它不在你写的任何Java代码里，也不在Class文件结构中显式定义——而是JVM在堆上为每个对象分配内存时，悄悄塞进对象头前8字节（64位虚拟机）里的一个4-bit字段。这个字段叫lock bits，和GC分代年龄、哈希码、偏向线程ID挤在同一块Mark Word里，靠位运算动态复用。
常见错误现象：用Unsafe.objectFieldOffset()去查markWord偏移量失败，或者反编译class看到hashCode()返回值和锁状态“对不上”，其实是同一片内存被不同阶段覆盖了。
-
Mark Word不是固定结构，开启-XX:+UseBiasedLocking时前54位可能存偏向线程ID，关了就腾出来放轻量级锁指针 - 调用
Object.hashCode()会强制将哈希码写入Mark Word，如果此时对象已加锁，就会触发锁膨胀并把哈希码挪到对象体外（比如java.lang.Class的_hash字段） - 32位JVM下
Mark Word只有4字节，锁标志位更紧凑，但兼容性差，现在基本只在嵌入式场景见得到
怎么验证当前对象处于哪种锁状态
不能靠synchronized语法糖猜，得看JVM运行时实际布局。最直接的方式是用jol（Java Object Layout）工具打印内存结构：
mvn org.openjdk.jol:jol-cli:0.16:run -Dexec.args="com.example.MyObj"
输出里找mark:那一行，末尾几个bit就是锁标志位。例如：0x0000000000000001表示无锁态，0x0000000000000005末两位01代表轻量级锁（具体编码见HotSpot源码markOop.hpp里的lock_mask_in_place）。
立即学习“Java免费学习笔记（深入）”；
- 必须用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly才能看到锁升级时Mark Word的实时变化，普通日志不输出这个细节 - 用
VisualVM或JMC只能看到线程阻塞统计，看不到单个对象的Mark Word值 - 自己写
Unsafe读取Mark Word要绕过JVM安全限制，且不同JDK版本字段偏移量可能变动，不推荐线上用
偏向锁关闭后，轻量级锁和重量级锁怎么切换
切换不是由Java代码控制的，而是JVM在同步块入口处通过CAS操作Mark Word失败次数决定的。关键阈值在BiasedLockingStartupDelay和BiasedLockingBulkRebiasThreshold这些参数里，但真正起作用的是ObjectSynchronizer::inflate()函数内部逻辑。
- 轻量级锁CAS失败4次（默认值，由
SpinLimit控制）后，JVM认为竞争变高，开始自旋；自旋再失败就膨胀成重量级锁 - 重量级锁一旦建立，
Mark Word里存的是指向ObjectMonitor结构的指针，而ObjectMonitor又包含_owner、_WaitSet等字段，这部分内存不在对象头里 - 调用
wait()或notify()会强制触发锁膨胀，哪怕之前一直是无锁或偏向态
为什么调试时看到的锁状态和预期不一致
因为Mark Word内容随时在变：GC移动对象会重写Mark Word，线程调度可能导致锁释放瞬间被其他线程抢占，甚至JIT编译器做了锁消除（-XX:+EliminateLocks），让synchronized根本没生成锁逻辑。
- 用
jstack看到locked <0x...>只说明线程持有monitor，不反映Mark Word当前值 - 在G1 GC下，如果对象在年轻代Survivor区反复复制，
Mark Word会被重置为初始无锁态，但锁记录可能还留在栈帧里 - 所有基于
Mark Word的分析都依赖“恰好抓到那个时刻”的快照，想稳定复现某一种锁状态，得配合-XX:BiasedLockingStartupDelay=0和手动触发Thread.yield()
真正难的不是看懂那几个bit，而是理解它们背后没有独立生命周期——它只是JVM在特定时机对同一块内存的不同解释方式。改一个参数、换一次GC、甚至多跑几毫秒，Mark Word就可能已经换了四轮含义。
