SpinWait.SpinUntil仅适用于等待极短时间内（微秒级）即可满足的轻量条件，如无锁结构中轮询volatile或Interlocked变量；不可用于I/O、网络、定时器等场景，且必须显式指定超时，谓词须无副作用、不阻塞、不分配。
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 和 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是静态方法，内部会管理好单次自旋上下文，无需你操心实例
