thread.onspinwait()是向cpu发出忙等提示的无副作用指令，仅适用于短时自旋场景，如无锁结构中轮询volatile标志位，jdk 9+支持，不可替代同步原语。
Thread.onSpinWait() 不是让线程“真正等待”，而是向 CPU 发出信号：当前在忙等，别乱调度、别降频、别瞎优化——它只对底层硬件和 JIT 有实际影响，Java 层面完全无阻塞、无状态、无副作用。
什么时候该用 Thread.onSpinWait()
只在你明确写了一个短时间、高概率立刻结束的自旋循环时才考虑。典型场景是无锁数据结构里轮询某个标志位（比如 AtomicBoolean 的 get() 结果），或等待另一个线程完成极轻量的初始化。
- ✅ 适用：
while (!ready.get()) { Thread.onSpinWait(); }，且ready通常在几纳秒到几十纳秒内变为true - ❌ 不适用：等待 I/O、锁、条件变量、超时逻辑、任何可能持续微秒以上的情况
- ❌ 不适用：JDK 8 或更早版本（会报
NoSuchMethodError）
Thread.onSpinWait() 和空循环、Thread.yield() 的区别
三者语义和效果完全不同：
- 空循环（
while (!flag);）：CPU 持续发射指令，可能触发分支预测失败、流水线冲刷，现代 CPU 甚至会主动降频 -
Thread.yield()：主动让出当前时间片，触发线程调度，开销远大于自旋，且不保证唤醒时机 -
Thread.onSpinWait()：JIT 编译后可能映射为 x86 的PAUSE指令或 ARM 的YIELD，仅提示 CPU “我在等，但别动我”，不改变线程状态，也不进调度队列
性能上，onSpinWait() 在热点自旋路径中可降低功耗 10–30%，并减少因频繁误预测导致的延迟毛刺。
立即学习“Java免费学习笔记（深入）”；
容易踩的坑和兼容性注意点
这个方法极易被误用，而且错误很难通过测试暴露：
- 它不解决竞态——你仍需正确使用 volatile /
VarHandle/Atomic*保证可见性；onSpinWait()加在非 volatile 变量上毫无意义 - OpenJDK 9+ 默认启用，但某些定制 JVM（如部分 Android ART 或嵌入式 JDK）可能未实现该 intrinsic，调用会退化为空操作（不报错）
- 不能替代
LockSupport.park()/unpark()或Condition.await()；它不是同步原语，也不参与 JMM 的 happens-before 推导 - 在虚拟机里（尤其启用了 CPU 节流的容器环境），
PAUSE指令效果可能被削弱，实测收益不如物理机明显
真正关键的是：它只在「已确认是短时自旋」的前提下才有价值，而绝大多数开发者根本没做过 cycle-level 的延迟测量，就直接加了 onSpinWait()——这时候它大概率只是给代码添了一行幻觉优化。
