轻量级锁不等同于自旋锁，而是基于cas操作的对象头锁状态升级机制；自旋仅在其获取失败时作为可选优化，由jvm自适应控制，用于减少短临锁竞争的上下文切换开销。
Java 中的轻量级锁（Lightweight Lock）并不直接等同于自旋锁（Spin Lock），但它在锁竞争不激烈时，会借助**自旋等待**来避免线程挂起，从而减少上下文切换开销。这种“自旋”行为是轻量级锁优化的一部分，而非其底层实现机制本身。
轻量级锁的核心机制不是自旋锁
轻量级锁是 JVM 在对象头（Mark Word）中通过 CAS 操作实现的一种锁状态升级策略，属于 偏向锁 → 轻量级锁 → 重量级锁 升级路径中的中间阶段。它的本质是：当多个线程交替获取同一把锁、无真正竞争时，用 CAS 替换 Mark Word 中的锁记录指针，避免进入操作系统互斥量。
而“自旋”只是在 尝试获取轻量级锁失败时的可选优化策略，由 JVM 参数控制（如 -XX:+UseSpinning，JDK 6 引入，JDK 7+ 默认开启，JDK 10 后移除该参数并改为自适应自旋）。
自旋如何介入轻量级锁获取过程
当一个线程发现目标对象已处于轻量级锁状态（即 Mark Word 指向了栈中某个线程的锁记录），但自己尚未持有该锁时，JVM 不会立即阻塞当前线程，而是可能执行有限次数的循环重试（即自旋），反复尝试 CAS 获取锁。这个过程发生在用户态，不涉及内核调度。
- 自旋期间线程保持运行状态，持续检查锁是否被释放（例如持有锁的线程是否已退出同步块）
- 自旋次数不是固定值，现代 JVM（如 HotSpot）采用 自适应自旋：根据前一次在该锁上自旋是否成功，动态调整本次自旋次数
- 若自旋成功（CAS 修改 Mark Word 成功），线程直接获得轻量级锁，继续执行
- 若自旋失败（达到阈值或锁仍未释放），JVM 将轻量级锁膨胀为重量级锁，当前线程被挂起，进入 Monitor 的 EntryList 等待
关键细节：自旋只发生在锁获取阶段，且仅对轻量级锁有效
需要明确的是：
- 自旋不会发生在偏向锁撤销过程中（那是 STW 的批量重偏向或全局撤销）
- 重量级锁状态下，线程等待走的是 ObjectMonitor 的 wait-set/entry-list，不自旋
- 自旋消耗的是 CPU 时间，适用于锁持有时间极短（比如几十纳秒到几微秒）的场景；若锁持有时间长，自旋反而浪费资源
- JDK 10 起，
-XX:+UseSpinning和-XX:PreBlockSpin已被移除，自旋逻辑完全由 JVM 自适应管理，无需手动配置
一个简化的行为示意
假设线程 T1 已持有对象 O 的轻量级锁（Mark Word 指向 T1 栈帧中的 Lock Record），此时线程 T2 尝试进入 synchronized(O)：
- T2 发现 Mark Word 是轻量级锁状态，且不属于自己的锁记录 → 触发锁竞争处理
- JVM 判断是否值得自旋（基于历史成功率、系统负载等）→ 决定执行自旋
- T2 执行若干次 CAS 尝试将 Mark Word 替换为自己锁记录的地址
- 若 T1 在此期间退出同步块（恢复 Mark Word 为无锁状态或升级为重量级锁），T2 可能抢到锁
- 否则，T2 自旋超时，触发锁膨胀，T2 阻塞等待
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
