SpinWait仅适用于预计等待极短（纳秒至微秒级）且竞争激烈但持续时间极短的场景，如自旋锁、无锁数据结构重试；误用于外部事件等待会导致CPU 100%。
SpinWait 适合在什么情况下用
SpinWait 不是通用的等待方案，只适用于「预计等待时间极短（纳秒到微秒级）」且「竞争非常激烈但持续时间很短」的场景，比如自旋锁内部、无锁数据结构的重试循环。它本质是让线程在用户态空转，不触发上下文切换，所以一旦等待时间稍长，CPU 占用会飙升，反而拖垮整体性能。
常见误用：用 SpinWait.SpinUntil 等待某个外部事件（如文件写入完成、网络响应），这会导致 CPU 100% 且毫无意义——这类场景该用 Task.Delay、ManualResetEventSlim 或异步 I/O。
SpinWait.SpinOnce 和 SpinWait.SpinUntil 的区别
SpinWait.SpinOnce 是最基础的单次自旋动作，它会根据当前线程调度状态决定是否调用 Thread.Sleep(0) 或 Thread.Yield()，也可能什么都不做（纯忙等）。它不带条件判断，必须配合手动循环使用。
SpinWait.SpinUntil 是封装好的轮询工具，接收一个 Func<bool></bool> 委托，在每次自旋后调用它检查条件是否满足。但它仍不处理超时，也不自动退避，容易卡死：
bool isReady = false;
// ❌ 危险：如果 isReady 永远不变成 true，这里无限空转
SpinWait.SpinUntil(() => isReady);
// ✅ 至少加个简单计数防死循环
int attempts = 0;
SpinWait.SpinUntil(() => {
if (isReady) return true;
return ++attempts > 10000;
});
为什么不能直接 while(true) { Thread.SpinWait(1); }
手写 Thread.SpinWait(n) 循环看似简单，但忽略了 .NET 运行时对自旋策略的动态优化：SpinWait 实例会随自旋次数增加自动升级行为（从空指令 → Thread.Yield → 最终可能让出时间片），而裸调 Thread.SpinWait 每次都是固定延迟，无法适应不同 CPU 核心数和调度压力。
正确做法是复用同一个 SpinWait 实例（避免重复初始化开销），并在循环中调用其 SpinOnce：
SpinWait spin = new SpinWait();
while (!conditionMet)
{
spin.SpinOnce(); // ✅ 自动退避
// 可选：加轻量级内存屏障防止重排序
Thread.MemoryBarrier();
}
注意：.NET 6+ 中 SpinWait 默认已内置轻量级屏障逻辑，一般无需额外 Thread.MemoryBarrier()，除非你明确在非 volatile 字段上做无锁读写。
和 ManualResetEventSlim 对比该怎么选
两者都用于短时同步，但语义和开销不同：ManualResetEventSlim 在等待初期也用自旋，但会自动降级为内核等待；SpinWait 始终不进内核，完全用户态。
- 用
ManualResetEventSlim：需要跨线程通知、可能等待稍久（毫秒级）、希望系统自动兜底 - 用
SpinWait：纯内存协作、确定等待极短（如 CAS 失败后立即重试）、追求极致低延迟且能控制重试逻辑
典型陷阱：在 lock-free 队列的 Enqueue 循环里混用 ManualResetEventSlim.Wait() —— 它会破坏无锁前提，且引入不必要的内核态切换。
