自旋锁通过让线程在用户态空转避免上下文切换，节省1000+时钟周期；仅适用于临界区极短场景，jvm对synchronized默认启用自适应自旋，而reentrantlock需手动实现。
自旋锁为什么能减少上下文切换？
因为自旋锁不把线程挂起，而是让线程在用户态“原地空转”，反复检查锁是否释放——跳过了从用户态切到内核态、再切回来的全过程。一次完整的上下文切换在现代 CPU 上要耗掉 1000+ 个时钟周期，而自旋只是几条汇编指令的循环，快得多。
但这只在锁持有时间极短（比如几十纳秒到几微秒）时才划算。一旦临界区稍长，自旋就变成纯烧 CPU 的无效等待。
- 典型适用场景：
synchronized块里只做字段赋值、简单计数器增减等轻量操作 - 明显不适用：
synchronized方法里调用了Thread.sleep()、Object.wait()或 I/O 操作 - JVM 默认开启自旋（JDK 6+），无需手动配置；但默认最多自旋
10次，超时即阻塞
自适应自旋怎么判断该旋多久？
它不是靠猜，而是基于历史行为动态调整：如果上次在同一个锁对象上自旋成功了，且持有锁的线程当时还在运行（没被 OS 调度走），JVM 就会多给这次自旋几次机会；反之，如果上次自旋失败了，这次可能直接跳过自旋，立刻阻塞。
这种策略让自旋更“懂”业务节奏，避免固定次数带来的误判——比如高并发下突发短临界区，固定 10 次可能不够；低负载下锁竞争稀疏，固定 10 次又纯属浪费。
- 开发者无法直接控制自适应逻辑，它是 JVM 内部实现（HotSpot 中由
ObjectSynchronizer::fast_enter等路径触发） - 可通过
-XX:PreBlockSpin=20手动设上限，但不推荐；自适应机制本身已比硬编码更可靠 - 注意：自适应只对同一锁对象有效；不同对象之间的自旋历史互不影响
什么时候自旋反而拖慢性能？
当锁被长时间占用，或多个线程在单核 CPU 上争一把锁时，自旋会吃光 CPU 时间片，还抢不到锁——其他线程得不到调度，持有锁的线程也难被唤醒，形成恶性循环。
尤其在 RocketMQ 这类高吞吐中间件中，早期用纯自旋锁（如 AtomicBoolean.compareAndSet() 循环）在消息体较大时，CPU 使用率飙升却吞吐不升，就是典型症状。
- 常见错误现象：
top显示某个 Java 进程 CPU 占用 90%+，但 QPS 却卡在低位 - 排查线索：用
jstack看线程堆栈，大量线程停在Unsafe.park前的自旋循环里（如AbstractQueuedSynchronizer.acquire调用链中） - 真实权衡点：不是“要不要自旋”，而是“要不要让自旋变得更聪明”——这也是 ABS 锁（Adaptive Backoff Spin Lock）在 RocketMQ 中落地的原因
JDK 中哪些地方实际用了自适应自旋？
最典型的就是 synchronized 关键字。JVM 在锁膨胀为重量级锁前，会先尝试轻量级锁 + 自适应自旋；只有多次自旋失败后，才升级并依赖操作系统 Mutex。
而 java.util.concurrent 包里的多数锁（如 ReentrantLock）默认不启用自旋，除非显式构造时传入 true（公平性参数不影响自旋，但 tryLock() 可配合手动自旋逻辑）。
-
synchronized是自动的、隐式的、与 JVM 深度绑定的自适应自旋 -
ReentrantLock不自带自旋，但你可以写while(!lock.tryLock()) { Thread.onSpinWait(); }模拟（JDK 9+ 提供Thread.onSpinWait()提示 CPU 当前是忙等待） - 别试图用
volatile+ 循环自己造自旋锁——容易漏掉内存屏障、ABA 问题、以及最关键的“何时退避”逻辑
自旋不是银弹，它把“等锁”的成本从“换线程”挪到了“烧 CPU”。真正难的是判断锁的持有时间分布——这没法靠配置解决，得靠压测时看 arthas 的 trace 结果，或者用 JFR 抓锁事件，否则很容易在生产环境里把自旋调成“CPU 烤箱”。
