轻量级锁本身不包含自旋逻辑，它只是锁升级过程中的一个中间状态；真正承担“避免阻塞”任务的是在轻量级锁竞争失败后、重量级锁生效前插入的自旋环节——这个环节独立于锁状态，但专为轻量级锁路径设计。
自旋发生在轻量级锁失败之后，而非锁内部
当线程尝试用 CAS 获取轻量级锁失败（说明已有其他线程持有），JVM 不会立刻膨胀为重量级锁，而是让当前线程进入一段有限循环：反复检查对象头是否已释放、是否可再次 CAS 成功。这段循环就是自旋，它发生在用户态，不触发线程挂起。
- 自旋不是轻量级锁的组成部分，而是它的“补救策略”
- 只有 synchronized 的轻量级锁路径才默认启用该机制；ReentrantLock 需依赖 AQS 的 tryAcquire 后续逻辑
- 自旋期间线程仍占用 CPU，但省去了从用户态切内核态再切回的开销（通常 >1000 个时钟周期）
自旋只对极短临界区有效
自旋能否成功，取决于持有锁的线程是否能在自旋耗尽前完成操作并释放锁。因此它只适用于纳秒级到微秒级的临界区，例如：
- 安全操作：int 型原子递增、boolean 标志位翻转、引用赋值
- 危险操作：任何 I/O、sleep()、wait()、数据库查询、复杂计算——这些会让自旋变成纯 CPU 浪费
- 若 jstack 显示大量线程卡在 Unsafe.park 前的 CAS 循环中，且 top 显示 CPU 高但吞吐低，大概率是自旋滥用
JDK 6+ 默认启用自适应自旋，无需手动干预
现代 JVM（JDK 6 起）不再使用固定次数自旋，而是根据历史行为动态调整：
立即学习“Java免费学习笔记（深入）”；
- 如果上次在同一把锁上自旋成功，且持锁线程仍在运行，本次会延长自旋次数
- 如果连续失败，则可能跳过自旋，直接走重量级锁路径
- 该机制由 HotSpot 内部自动管理，开发者不能修改其策略，也不建议通过 -XX:PreBlockSpin 硬设上限
- 自适应仅对同一锁对象生效，不同对象之间互不影响
自旋失败就必然膨胀为重量级锁
一旦自旋耗尽仍未获取锁，JVM 会执行不可逆的锁膨胀：将对象头 Mark Word 替换为指向操作系统 Mutex 的指针，后续所有竞争者都将被挂起、进入 Monitor 阻塞队列。此时线程调度权交还给操作系统，上下文切换开销回归高位。
- 膨胀是单向的：轻量级锁 → 重量级锁，不会降级
- 膨胀后，即使竞争消失，该锁对象也永久保持重量级状态
- 所以自旋本质是“赌一把”：赌持有线程很快释放——赢了省开销，输了就进重量级队列
