竞争条件（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;
<p>// 正确：每次访问都走同一把锁
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<t></t>、
ConcurrentDictionary<k></k>：内部已优化，不用自己加锁
最容易被忽略的坑：异步 + 锁 = 危险组合
lock是同步原语，不能跨
await边界。下面这段代码会编译通过，但运行时锁失效：
public async Task BadExample()
{
lock (_lockObj) // ❌ 锁在 await 前就释放了！
{
await Task.Delay(100);
_counter++;
}
}
正确做法：要么把异步操作移出锁外（如果逻辑允许），要么改用 SemaphoreSlim.WaitAsync()（它支持 await） 更隐蔽的坑：在
async void方法里加锁，异常可能逃逸导致锁未释放 —— 永远优先用
async Task调试提示：若发现“有时正常、有时错”，且涉及
await和共享状态，先检查是否误用了同步锁
真正难的从来不是“知道要用锁”，而是判断“哪里是临界区”“锁的粒度是否合理”“有没有隐藏的跨线程共享”。哪怕只有一处漏掉同步，整个多线程逻辑就不可信。
