Thread.onSpinWait优化自旋锁技巧

Thread.onSpinWait() 是 JDK 9 引入的精细化 CPU 提示机制，专为极短时延（

Thread.onSpinWait() 不是让线程“休息”，而是告诉 CPU “我在等，但别动我”

它不是 Thread.yield()，也不是 Thread.sleep(0)，更不是 LockSupport.park()。它的唯一作用是向 CPU（特别是 x86）发出一个轻量提示：当前执行流正处于极短的自旋等待中，请暂停分支预测激进优化、降低内存屏障强度、避免过早触发上下文切换调度。在 ARM 或 RISC-V 上，它目前就是空操作。

这意味着：如果你在等待网络响应、数据库返回、文件读取完成时调用它，只会白耗 CPU；只有当等待目标是另一个线程对 volatile 字段或原子变量的瞬时修改（预期延迟

必须配合 volatile 读，否则 JIT 可能直接优化掉整个循环

Thread.onSpinWait() 本身不读内存，也不产生 happens-before 关系。如果轮询的变量不是 volatile，JIT 编译器很可能把它当成常量缓存到寄存器里，导致死循环——你永远看不到其他线程写入的新值。

• ✅ 正确写法：while (!ready) { Thread.onSpinWait(); }，其中 ready 是 volatile boolean 或由 AtomicBoolean.get() 读取
• ❌ 错误写法：while (value == 0) { Thread.onSpinWait(); }，value 是普通 int 字段
• ⚠️ 注意：AtomicInteger.compareAndSet() 失败后重试时，必须先读取最新值（如 get()），再判断是否继续，不能只靠 CAS 返回值隐式轮询

不能每轮都调用，要限频 + 退避，否则提示失效甚至拖慢唤醒

频繁调用 onSpinWait() 不会提升性能，反而可能干扰 CPU 的 pause 指令节拍节奏。实测表明，在 x86 上每 4–8 次失败重试调用一次效果较稳；超过 10–15 轮仍没成功，就该放弃自旋，改用 LockSupport.parkNanos(100) 或直接交由锁机制处理。

• 推荐模式：if ((retries & 0x7) == 0) Thread.onSpinWait();
• 高争用下若发现多个线程长期在自旋，CPU 使用率飙升但吞吐未升，说明已超出适用边界
• 混用陷阱：在 park() 前加 onSpinWait() 没意义；在 park() 失败回调里无脑重试 + onSpinWait()，会导致唤醒延迟升高

它只在 JDK 9+ + HotSpot + 支持 PAUSE 的 CPU 上才可能内联为真实指令

即使代码写了 onSpinWait()，JVM 也未必真生成 PAUSE 指令。它依赖 JIT 编译器识别并内联，而该优化在 debug 模式、低编译层级（C1）、或非 HotSpot VM（如 Zing、OpenJ9）中大概率被跳过。ARM64 平台目前只是空实现，别指望有收益。

生产环境上线前，建议用 -XX:+PrintAssembly（需 hsdis）确认关键循环是否真生成了 pause 指令；或者用 JMH 写对比微基准，观测 CPI（cycles per instruction）和 L1D 缓存未命中率变化。

真正难的是判断“到底该不该自旋”——这取决于临界区长度、竞争强度、硬件缓存一致性协议行为，而不是多加一个 onSpinWait() 就能解决。

到这里，我们也就讲完了《Thread.onSpinWait优化自旋锁技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！