轻量级锁加锁时必须自旋而非挂起线程，因挂起/唤醒涉及用户态到内核态切换，开销远大于用户态空转几个cpu周期；jvm默认仅在多核环境下自旋，且自旋次数由自适应策略动态调整。
轻量级锁加锁时为什么必须自旋而不是直接挂起线程
因为挂起/唤醒线程涉及用户态到内核态切换，开销远大于在用户态空转几个 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，它早就不起作用了。
