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 方法，或者读的时候依赖了另一个未加锁的全局状态，这时候加再多读锁也没用。
