轻量级锁自旋与CAS机制解析

本文深入剖析了Java轻量级锁的核心机制，重点揭示了为何必须采用自旋等待而非线程挂起——本质在于避免昂贵的用户态/内核态切换开销，同时强调JVM自旋策略完全动态自适应、无硬编码阈值；详细拆解了CAS如何安全修改Mark Word指向栈中Lock Record、重入时计数器在栈帧内维护的巧妙设计，以及自旋失败后锁膨胀的真实触发逻辑：非简单轮次耗尽，而是结合线程状态、统计历史与运行时环境综合决策。理解这些，才能真正摆脱对过时参数（如PreBlockSpin）的迷信，在高并发场景下做出精准的性能诊断与调优。

轻量级锁加锁时为什么必须自旋而不是直接挂起线程

因为挂起/唤醒线程涉及用户态到内核态切换，开销远大于在用户态空转几个 CPU 周期。JVM 默认只允许 os::is_MP() 为 true 的场景下自旋（即多核），且自旋次数受 -XX:PreBlockSpin 控制（Java 6 后已废弃，实际由自适应策略接管）。

常见错误现象：Thread.State = BLOCKED 却发现竞争并不激烈——说明自旋未生效，可能因锁被其他线程长时间持有，或 JVM 认定当前线程不适合自旋（如已自旋失败过、CPU 负载高）。

• 自旋不是无限的：JVM 会根据前一次获取锁的成功率动态调整，失败则降级为重量级锁
• 自旋期间线程仍占用 CPU，若锁持有时间长，反而浪费资源
• 单核 CPU 上默认禁用自旋，因为无法真正“并发”，只会白占调度时间

Mark Word 如何通过 CAS 指向栈帧中的 Lock Record

轻量级锁加锁本质是用 CAS 将对象头的 Mark Word 替换为指向当前线程栈中 Lock Record 的指针。这个指针不是任意地址，而是栈帧里一块固定结构的内存（包含原始 Mark Word 备份和对象头指针）。

关键点在于：CAS 必须成功，否则说明有竞争，进入自旋或膨胀流程。失败后不能重试无限次，否则导致 ABA 问题或饥饿。

• Lock Record 在栈上分配，生命周期与方法调用一致；逃逸分析失败时可能被分配到堆，但此时轻量级锁通常已失效
• CAS 修改的是对象头低 3 位为 00（表示轻量级锁状态），同时写入指向 Lock Record 的指针
• 若 CAS 失败，说明 Mark Word 已被其他线程修改（比如已被锁、或正在膨胀），需检查是否为重入（对比线程 ID）

为什么重入时不新建 Lock Record 而是计数

重入时 JVM 会检查 Mark Word 中存储的线程 ID 是否与当前线程一致。一致则跳过 CAS，直接在栈帧已有 Lock Record 的 displaced_mark_word 区域叠加一个计数器（实际存于 Lock Record 后续字段，非 Mark Word 本身）。

这样做避免了重复分配栈空间，也防止多次 CAS 引发不必要的竞争。但要注意：计数器不存于对象头，而是在每个线程自己的栈帧里维护，所以跨线程不可见。

• 计数器溢出（超过 0x3FFFFFFF）会导致锁膨胀，但现实中几乎不会发生
• 解锁时按计数器倒序还原 Mark Word，最后一次才真正恢复原值
• 若重入期间发生锁膨胀，计数器信息会丢失，后续解锁行为由重量级锁机制接管

自旋等待失败后锁膨胀的临界判断逻辑

膨胀不是一蹴而就的。当自旋一定轮次后仍未获得锁，JVM 会检查当前 Mark Word 状态：若仍是轻量级锁状态（即指向某线程栈帧），但该线程已阻塞或长时间未释放，则触发膨胀；若已是偏向锁状态，则先撤销再膨胀。

典型错误认知：认为“自旋失败=立刻膨胀”。实际上 JVM 会先尝试让出 CPU（os::NakedYield()），再检查是否需要升级。这中间可能穿插 GC、线程调度等干扰。

• 膨胀时需将所有 Lock Record 中的备份 Mark Word 拷贝回对象头，并设置锁标志位为 10（重量级锁）
• 原轻量级锁持有线程继续运行，但后续争抢者全部进入 ObjectMonitor 的 _EntryList 或 _WaitSet
• 膨胀过程本身是同步的，由第一个检测到需膨胀的线程执行，其余线程等待其完成

真正容易被忽略的是：自旋策略和膨胀阈值完全由 JVM 运行时采集的统计信息驱动，没有硬编码阈值。同一段代码，在不同负载、不同 GC 阶段、不同 CPU 亲和性下，可能走完全不同的锁路径。别迷信 -XX:PreBlockSpin，它早就不起作用了。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《轻量级锁自旋与CAS机制解析》文章吧，也可关注golang学习网公众号了解相关技术文章。