Java 轻量级锁（Lightweight Lock）的自旋机制，并不直接“通过 Mark Word 实现自旋”，而是利用 Mark Word 的状态标记配合线程栈中的锁记录（Lock Record），在竞争不激烈时让线程在用户态循环检测（即自旋），避免立即挂起/唤醒开销。Mark Word 本身不执行自旋，但它是轻量级锁状态切换和自旋判断的关键依据。
轻量级锁加锁时 Mark Word 怎么变
当一个线程尝试获取未被锁定的对象时：
- 若对象处于无锁状态（Mark Word 高 2 位为 01，后 23/57 位为 hashcode 或 age 等），JVM 会在当前线程的栈帧中创建一个 Lock Record（锁记录），把对象当前的 Mark Word 拷贝进去作为 Displaced Mark Word；
- 接着用 CAS 尝试将对象头的 Mark Word 替换为指向该 Lock Record 的指针（此时 Mark Word 高 2 位变为 00，表示轻量级锁状态）；
- 如果 CAS 成功，加锁完成；失败说明有其他线程已抢占，进入自旋逻辑。
自旋怎么触发和依赖 Mark Word
自旋发生在 CAS 加锁失败后，线程不会立刻阻塞，而是循环检查：
- 对象头 Mark Word 是否仍为指向其他线程 Lock Record 的指针（即是否还在轻量级锁状态）；
- 如果是，再检查那个 Lock Record 所属线程是否还存活、是否已释放锁（例如：Lock Record 中的 Displaced Mark Word 是否已被写回对象头）；
- 若发现锁已被释放（比如 Mark Word 已恢复为无锁状态 01），则再次尝试 CAS 获取；
- 若多次自旋后仍未成功（默认 10 次，由 -XX:PreBlockSpin 控制），升级为重量级锁（Mark Word 高 2 位变为 10，指向 Monitor）。
为什么自旋能减少上下文切换
因为整个过程不涉及操作系统线程调度：
立即学习“Java免费学习笔记（深入）”；
- 自旋只是在用户态反复读取对象头 Mark Word 和本地 Lock Record，是纯 CPU 操作；
- 只要持有锁的线程很快释放（比如临界区极短），等待线程大概率在自旋期间看到锁释放并抢到，完全避免了 sleep/wakeup 开销；
- Mark Word 的原子性读写（尤其是 CAS 更新）保证了多线程下状态判断的可靠性。
注意：自旋不是无限的，也不是万能的
自旋有效前提是锁持有时间短、竞争不激烈：
- 若自旋过久，会浪费 CPU；JVM 有自旋次数阈值，超限就膨胀为重量级锁；
- 若多个线程同时自旋，可能引发总线风暴（频繁读写同一缓存行），现代 JVM 会结合适应性自旋（根据前一次自旋是否成功动态调整次数）；
- Mark Word 的结构必须可被准确解读——32 位/64 位 JVM、是否开启压缩指针（UseCompressedOops）都会影响其布局，但自旋逻辑对这些透明，只依赖状态位和指针有效性。
