SpinLock 和 lock 的底层行为完全不同
lock是语法糖，本质调用
Monitor.Enter和
Monitor.Exit，线程拿不到锁就立刻进入等待态，让出 CPU，触发上下文切换；而
SpinLock是纯用户态结构，拿不到锁时线程不放弃 CPU，持续用
Interlocked.CompareExchange检查状态——也就是“空转”，直到成功获取锁。 这意味着
lock在争用高、临界区长时更省 CPU，但每次切换代价约 1–10 微秒
SpinLock避免了切换开销，但若临界区超过几微秒（比如含
Thread.Sleep(1)或 I/O），自旋反而更慢、还拖高 CPU 使用率
SpinLock是值类型（
struct），不能跨线程共享实例；
lock锁的是引用对象（如
private static readonly object _lock = new object()）
什么时候该选 SpinLock？看三个硬指标
不是“并发高就上 SpinLock”，而是必须同时满足：
临界区逻辑极短：纯内存操作，无阻塞、无调度点，执行时间稳定在 锁争用低或中等：高争用下多个线程同时自旋，CPU 白白拉满，却谁也进不去 临界区不含任何可能触发 GC 或异常传播的代码：因为SpinLock.Enter不是异常安全的——若临界区抛异常且没正确
Exit，会导致死锁（同一线程后续再
Enter就卡住）
反例：
lock更适合大多数场景，比如数据库连接池管理、缓存写入、日志缓冲区追加——哪怕只多一行
if (obj == null) return;，都建议别碰
SpinLock。
常见误用和崩溃现场
下面这些写法看似合理，实际会立即出问题：
把SpinLock实例定义成
static并在多线程间复用：可以，但必须确保每个线程都用
ref bool lockTaken正确配对
Enter/Exit在
async方法里用
SpinLock：绝对禁止。await 后续回调可能在不同线程执行，
Exit调用会抛
InvalidOperationException（“只能由持有锁的线程释放”） 忘记检查
lockTaken就直接调用
Exit：一旦
Enter失败（比如超时未设、或被中断），
Exit会崩 重复
Enter同一个
SpinLock实例（不可重入）：同一线程第二次调用
Enter就死锁，
IsHeld属性也无法救场
private static SpinLock _spinLock = new SpinLock();
private static int _counter = 0;
public void Increment()
{
bool lockTaken = false;
try
{
_spinLock.Enter(ref lockTaken); // 必须传 ref！
_counter++;
}
finally
{
if (lockTaken) _spinLock.Exit(); // 必须判空！
}
}
性能对比不能只看吞吐，要看 CPU 效率
在 100 线程、每轮临界区仅 50 纳秒的纯计数场景下，
SpinLock可能比
lock快 3–5 倍；但只要临界区加入一次
Interlocked.Increment以外的操作（比如查字典、拼字符串），优势就消失；若临界区平均耗时 > 2 微秒，
SpinLock的 CPU 占用率常飙到 300%+，而吞吐反而更低。 调试时注意：Windows 性能监视器里看
% Processor Time+
Context Switches/sec，二者此消彼长 上线前务必压测：用
dotnet-trace录制真实负载，观察
SpinLock自旋循环是否成为热点（方法名含
TryEnter或
SpinOnce） 没有银弹：.NET 6+ 中，多数短临界区场景优先考虑
Interlocked（如
Interlocked.Add），它比
SpinLock更轻、更安全、还能跨平台保证语义 真正难的不是选哪个锁，而是判断“这段代码到底算不算短临界区”——它取决于你的硬件、当前 GC 压力、甚至 JIT 编译模式。实操中，先用
lock写稳，再用
dotnet-counters看
monitor-lock-contention-rate，如果每秒争用低于 10 次，基本不用换；高于 100 次且确认临界区干净，才值得尝试
SpinLock。
