竞争条件在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和共享状态，先检查是否误用了同步锁
真正难的从来不是“知道要用锁”，而是判断“哪里是临界区”“锁的粒度是否合理”“有没有隐藏的跨线程共享”。哪怕只有一处漏掉同步，整个多线程逻辑就不可信。
