c# 什么是竞争条件 c#如何避免Race Condition

竞争条件在C#中必然发生，因++等操作非原子；应使用lock（配私有静态readonly对象）或Interlocked等专用方案，禁用lock(new object())及异步锁。

竞争条件（Race Condition）在 C# 中不是“会不会发生”的问题，而是“只要没同步，就一定会发生”的现实——尤其当你用 ++、--、+= 等非原子操作读写同一个变量，且该变量被多个线程共享时。

为什么 counter++ 会出错？

它看起来是一行代码，实际是三步：读取 → 修改 → 写回。两个线程可能同时读到 counter == 5，各自加 1 后都写回 6，结果本该是 7 却仍是 6。这不是偶发 bug，是必然逻辑漏洞。

• 典型错误场景：多线程计数器、缓存更新、串口/文件句柄复用、共享配置对象修改
• 现象：最终值总比预期小（累加类）、数据重复或丢失（集合 Add 类）、偶尔抛 InvalidOperationException（如非线程安全集合被并发修改）
• 注意：int 读写本身是原子的（x64/x86 下对齐 4 字节变量），但 counter++ 不是；long 在 32 位环境甚至读写都不原子

最常用且推荐的解决方式：用 lock 保护临界区

这是绝大多数场景下最直观、最可控、最容易审计的方案。关键不是“加锁”，而是“锁得对”——锁对象必须是私有、静态、不可变的引用类型实例。

private static readonly object _lockObj = new object();
private static int _counter = 0;
// 正确：每次访问都走同一把锁
public static void Increment()
{
lock (_lockObj)
{
_counter++;
}
}

• ❌ 错误示范：lock(new object())（每次新建对象，完全不互斥）、lock(this) 或 lock(typeof(MyClass))（外部可访问，破坏封装）
• ✅ 好习惯：用 readonly + static 确保锁对象唯一且不可重赋值
• ⚠️ 注意：锁内避免调用未知外部方法（可能阻塞或引发死锁），也别做耗时 I/O 操作

更轻量或更专用的替代方案

不是所有场景都需要 lock。根据需求选更匹配的工具，能减少开销或提升可读性：

• 纯数值增减 → 用 Interlocked.Increment(ref _counter)：无锁、原子、零等待，但仅支持简单整数运算
• 需要跨进程同步（如多个 .NET 进程共用一个配置文件）→ 用 Mutex：系统级，性能低，但必要时不可替代
• 限制并发访问数（如最多 3 个线程同时调用 API）→ 用 SemaphoreSlim(3)：比 lock 更灵活，支持异步等待 WaitAsync()
• 共享集合（队列/字典/栈）→ 直接用 ConcurrentQueue、ConcurrentDictionary：内部已优化，不用自己加锁

最容易被忽略的坑：异步 + 锁 = 危险组合

lock 是同步原语，不能跨 await 边界。下面这段代码会编译通过，但运行时锁失效：

public async Task BadExample()
{
    lock (_lockObj) // ❌ 锁在 await 前就释放了！
    {
        await Task.Delay(100);
        _counter++;
    }
}

• 正确做法：要么把异步操作移出锁外（如果逻辑允许），要么改用 SemaphoreSlim.WaitAsync()（它支持 await）
• 更隐蔽的坑：在 async void 方法里加锁，异常可能逃逸导致锁未释放 —— 永远优先用 async Task
• 调试提示：若发现“有时正常、有时错”，且涉及 await 和共享状态，先检查是否误用了同步锁

真正难的从来不是“知道要用锁”，而是判断“哪里是临界区”“锁的粒度是否合理”“有没有隐藏的跨线程共享”。哪怕只有一处漏掉同步，整个多线程逻辑就不可信。