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

来源：这里教程网时间：2026-02-21 17:36:31 作者：

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