c# ReaderWriterLockSlim 怎么用 c#读写锁和普通锁的区别

ReaderWriterLockSlim适用于读多写少场景，允许多读单写；需严格配对Enter/Exit、避免跨线程释放；EnterUpgradeableReadLock用于读-判-写原子操作，但不支持递归；常见错误包括锁泄漏、LockRecursionException和SynchronizationLockException。

ReaderWriterLockSlim 是 C# 里专为“读多写少”场景设计的高性能读写分离锁，它和 lock 的核心区别不是“能不能用”，而是“并发模型完全不同”——lock 一锁全堵，ReaderWriterLockSlim 允许多个线程同时读，只在写时才排他。

什么时候该用 ReaderWriterLockSlim 而不是 lock

看你的共享资源访问模式是否符合这三点：

• 读操作远多于写操作（比如缓存查询、配置读取、状态快照）
• 读操作本身不修改数据，且多个读线程之间无副作用
• 你观察到 lock 成为性能瓶颈，尤其在高并发读场景下 CPU 等待时间明显上升

反例：如果读操作偶尔要“顺手改点东西”，或写操作频率接近读操作，那 ReaderWriterLockSlim 不但没优势，反而因状态切换开销更慢。

EnterReadLock / EnterWriteLock 怎么配对才不出错

必须严格成对调用，且不能跨线程释放 —— 这是它和 lock 最容易混淆的坑。下面这些写法都是危险的：

• 在 try 块外调用 EnterReadLock，然后进 try 后抛异常 → ExitReadLock 永远不执行 → 锁泄漏
• 用 using 包裹（它不实现 IDisposable）→ 编译失败
• 在异步方法中用了 await 后还试图 ExitReadLock → 当前线程已变，ExitReadLock 会直接抛 LockNotHeldException

正确姿势永远是：

cacheLock.EnterReadLock();
try
{
    return innerCache.TryGetValue(key, out var value) ? value : null;
}
finally
{
    cacheLock.ExitReadLock();
}

EnterUpgradeableReadLock 是什么？为什么别乱用

它解决的是“先读再决定要不要写”的典型场景（比如：查缓存没命中就加载并写入），避免两次加锁 + 中间被其他写线程篡改的风险。但它不是“读锁+写锁”的快捷方式，而是有明确约束：

• 同一时刻只能有一个线程持有可升级读锁（EnterUpgradeableReadLock）
• 升级前必须确保没有其他线程正在写，否则 EnterWriteLock 会阻塞
• 一旦升级成功，原可升级读锁自动释放，不能再回退（除非你手动先 EnterReadLock 再 ExitUpgradeableReadLock）
• 不支持递归：不能在已持可升级读锁的线程里再次调用 EnterUpgradeableReadLock

简单说：它适合“读-判断-写”原子性要求强、且写操作极少的逻辑；如果写逻辑复杂或可能失败，建议拆成“先读 → 释放读锁 → 再争写锁”，更可控。

常见报错和兼容性注意点

这几个错误最常出现在迁移老代码时：

• LockRecursionException：默认构造的 ReaderWriterLockSlim() 不支持递归加锁，哪怕同一线程重复 EnterReadLock 都会崩。如真需递归，得显式传 LockRecursionPolicy.SupportsRecursion，但官方强烈不推荐
• SynchronizationLockException：当前线程没持锁却调用了 ExitReadLock 或 ExitWriteLock，多见于异常路径遗漏 finally
• .NET Framework 4.0+ 和 .NET Core / .NET 5+ 行为一致，但旧版 ReaderWriterLock（已废弃）性能差、易死锁，千万别混用

真正难的不是怎么写，而是判断“这个读是不是真的可以并发”——比如读操作里悄悄调了某个非线程安全的 helper 方法，或者读的时候依赖了另一个未加锁的全局状态，这时候加再多读锁也没用。