SpinWait.SpinUntil 什么时候该用、什么时候不该用
它只适合等待一个几乎立刻就能变成
true的条件，比如等待某个标志位被另一个线程极快地设置。一旦等待时间超过几微秒到几十微秒，
SpinWait.SpinUntil就开始浪费 CPU，比直接用
Task.Wait或
Monitor.Wait更低效。
常见误用场景包括：等 I/O 完成、等数据库响应、等网络回调、等定时器触发——这些统统不该自旋。
适合：无锁结构中等待另一个线程更新一个volatile字段或
Interlocked变量 不适合：替代
Thread.Sleep、
AutoResetEvent.WaitOne、
Task.Delay(...).Wait()风险：在单核 CPU 或线程被抢占时，可能无限循环（除非传入超时）
SpinUntil 的参数和超时必须显式控制
SpinWait.SpinUntil有两个重载，最常用的是带
Func<bool></bool>和
TimeSpan的那个。不传超时（只用谓词版本）等于裸奔——没有兜底机制，一旦条件永不满足，线程就卡死。
即使加了超时，也要注意：超时后方法返回
false，但自旋本身不会主动中断正在执行的谓词；如果谓词里有副作用或耗时操作，超时判断会被延迟。 务必使用带
TimeSpan的重载，例如：
SpinWait.SpinUntil(() => ready, TimeSpan.FromMilliseconds(10))谓词函数应轻量：只读字段、
Interlocked.Read、
Volatile.Read，避免锁、IO、分配 不要在谓词里调用
Thread.Sleep或
await—— 它不是异步方法
自旋等待 vs 阻塞等待：底层行为差异很实在
自旋是“忙等”：线程持续占用 CPU 周期反复检查条件，不放弃执行权；阻塞等待（如
ManualResetEvent.WaitOne）会让线程进入内核等待状态，交出 CPU，由操作系统调度唤醒。
这意味着：
自旋在多核且等待极短时延迟更低（避免用户态/内核态切换开销） 阻塞等待在任意等待时长下都更省电、更公平，尤其在线程数 > 核心数时SpinWait内部会自动退避（spin → pause → yield），但它无法感知系统负载，退避策略固定
var spin = new SpinWait();
while (!condition && !timeoutElapsed)
{
if (spin.NextSpinWillYield) Thread.Sleep(0); // 它自己决定何时让出
spin.SpinOnce();
}
容易被忽略的细节：SpinWait 实例不能复用、也不该共享
每个
SpinWait实例维护自己的退避状态（比如已自旋多少次、是否该 yield）。多个线程共用同一个实例会导致退避逻辑错乱，可能过早 yield 或迟迟不 yield。
官方文档明确说：
SpinWait实例不应跨线程共享，也不建议缓存复用。每次需要自旋，就用静态方法
SpinWait.SpinUntil，或者新建局部实例。 错误写法：
private static readonly SpinWait s_wait = new();然后多线程调用
s_wait.SpinOnce()正确写法：直接调用
SpinWait.SpinUntil(...)，或在方法内
var wait = new SpinWait(); while(...) wait.SpinOnce();注意：
SpinWait.SpinUntil是静态方法，内部会管理好单次自旋上下文，无需你操心实例
