17370845950

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.FromMillis

  

  econds(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 是静态方法，内部会管理好单次自旋上下文，无需你操心实例