轻量级锁的获取依赖CAS成功或有限自旋，失败则膨胀为重量级锁；其核心是用户态下基于CAS的无锁化竞争，适用于极短临界区，不适用于I/O或耗时操作。
轻量级锁本身不等于自旋，但它的竞争获取过程依赖自旋 + CAS 的组合机制——这是 JVM 在用户态下平衡响应速度与 CPU 开销的关键设计。
轻量级锁的获取本质是“一次成功的 CAS + 可选的有限自旋”
当线程尝试进入 synchronized 同步块时，若对象处于无锁或已撤销偏向状态，JVM 会在当前线程栈中创建 Lock Record，并尝试用 CAS 将对象头（Mark Word）更新为指向该记录的指针。这个 CAS 成功即代表轻量级锁获取成功；失败则说明已有其他线程抢先获取了该锁。
此时，JVM 不会立即升级为重量级锁，而是让当前线程在用户态做短时间自旋：反复尝试 CAS，等待持有锁的线程快速释放。这种自旋不是无限循环，而是受参数 -XX:PreBlockSpin 控制（默认 10 次），或由 JVM 自适应策略动态调整。
- CAS 成功 → 锁获取完成，不涉及内核态切换，耗时通常在纳秒级
- CAS 失败且未超自旋阈值 → 继续下一轮 CAS 尝试
- 自旋次数耗尽仍失败 → 轻量级锁膨胀为重量级锁，线程挂起
自旋不是白忙，但必须控制成本
自旋的价值在于避免上下文切换——一次用户态到内核态的切换开销可达微秒级，而几十次 CAS 循环可能还不到 1 微秒。但前提是锁被持有时间足够短（比如临界区仅执行几条赋值或计数操作）。
如果临界区包含 I/O、sleep、复杂计算或锁嵌套，自旋就失去意义：线程白白占用 CPU，还可能拖慢其他真正需要执行的任务。
- 适合场景：高频、极短临界区，如原子计数器递增、缓存状态标记更新
- 不适合场景：同步块内调用远程接口、数据库查询、文件读写
- 优化提示：可通过 -XX:+UseSpinning（JDK 6~8）或自适应自旋（JDK 9+ 默认启用）提升命中率
CAS 是轻量级锁竞争的唯一原子基元
整个轻量级锁的竞争逻辑完全建立在 CAS 之上：无论是将 Mark Word 替换为指向 Lock Record 的指针，还是后续自旋中重试该操作，都依赖 Unsafe 类调用 CPU 级的 cmpxchg 指令。它不依赖操作系统互斥量，也不申请任何内核资源。
正因为如此，轻量级锁才能做到“无锁化竞争”——没有阻塞、没有唤醒队列、没有等待线程的调度介入。但它也继承了 CAS 的固有约束：
- ABA 问题不影响锁升级路径（因 Mark Word 结构含锁状态位和线程ID，非纯数值）
- 高竞争下大量 CAS 失败会推高总线流量，多核间缓存一致性开销上升
- 单核 CPU 上自旋几乎无收益，反而挤占本可运行的其他线程时间片
实际调试中可观察锁升级痕迹
通过 JVM 参数 -XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+PrintSafepointStatistics，配合 JFR 或 JITWatch，能捕获锁膨胀事件。例如日志中出现 “BiasedLockingRevoked” 或 “FastMonitorEnter failed, inflating…” 即表明轻量级锁已失效并转向重量级路径。
这类信号提示你：当前同步点的实际竞争强度已超出轻量级锁的设计舒适区，需检查是否临界区过长、是否存在隐式锁竞争（如 String.intern）、或是否应改用更细粒度的锁/无锁结构（如 LongAdder、StampedLock）。
