Thread.SpinWait 是纯用户态的忙等待
Thread.SpinWait完全运行在用户态，不触发系统调用，也不涉及线程挂起、调度器介入或内核态切换。它本质就是执行一连串空的 CPU 指令（如
PAUSE指令在 x86 上），让当前线程“原地空转”指定次数，同时向 CPU 暗示当前处于自旋等待状态，有助于降低功耗和改善超线程性能。
这意味着：
调用Thread.SpinWait(n)不会进入阻塞状态，操作系统不会将其线程标记为“等待中”，也不会从调度队列移除 不会产生上下文切换开销，也没有内核态/用户态转换成本 适用于预期等待时间极短（通常 滥用会导致 CPU 占用率飙升，尤其在单核或高负载环境下，可能饿死其他线程
为什么 Thread.SpinWait 不会进内核态
因为它的实现不依赖任何 OS 同步原语——它不调用
WaitForSingleObject、
futex或类似机制。.NET 运行时对
Thread.SpinWait的底层实现直接映射到平台特定的“提示性暂停”指令： Windows x64：生成
PAUSE指令（非特权指令，用户态可安全执行） Linux x64：同样使用
PAUSE；ARM64 则用
YIELD所有路径都绕过 CLR 的同步基础设施（如
Monitor内部的内核事件对象）
你可以通过反编译
Thread.SpinWait看到它最终调用的是
RuntimeHelpers.SpinWait，而后者是 JIT 内联的硬编码指令序列，无托管/非托管过渡。
SpinWait 和 Monitor.Enter / Task.Delay 的关键区别
对比常见等待方式，能更清楚定位
Thread.SpinWait的适用边界：
Monitor.Enter：前几次尝试获取锁失败时，CLR 可能自动插入短时自旋（含
PAUSE），但一旦检测到竞争持续，会立刻升级为内核事件等待（
CreateEvent+
WaitForSingleObject）
Task.Delay(1)：必然触发计时器队列注册 + 线程池回调，涉及内核定时器对象和至少一次上下文切换
Thread.Sleep(0)：主动让出当前时间片，强制触发调度器介入，属于内核态行为
Thread.SpinWait(100)：仅消耗约几百纳秒 CPU 时间，无调度干预，不可替代上述任一语义
实际使用时容易踩的坑
开发者常误把它当“轻量 Sleep”来用，这是危险的。典型错误包括：
在循环里写while (!ready) Thread.SpinWait(1000);—— 若
ready长时间不置位，CPU 占用率会飙到 100% 用它替代
AutoResetEvent.WaitOne()或
ManualResetEvent.WaitOne()—— 丢失阻塞+唤醒语义，无法响应信号 忽略硬件差异：在老式 CPU（如没有
PAUSE优化的 Atom）上，
SpinWait效果接近无意义空循环，甚至更差 未配合内存屏障：自旋读取共享变量时，必须用
Volatile.Read或
Thread.VolatileRead，否则可能因 CPU 重排序或寄存器缓存导致永远看不到更新
bool ready = false; // 错误：可能无限循环（编译器/CPU 都可能缓存 ready 值） while (!ready) Thread.SpinWait(10); // 正确：确保每次读取都从主内存获取 while (!Volatile.Read(ref ready)) Thread.SpinWait(10);真正需要
Thread.SpinWait的地方极少，基本只出现在高性能同步原语（如
SpinLock、
LazyInitializer）的底层实现中。业务代码里看到它，大概率说明设计出了问题。
