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（已废弃）性能差、易死锁，千万别混用