C#中ReaderWriterLock的AcquireWriterLock能否替代常规lock(){}？

首先得明确：两者确实都是排他锁——同一时间只能有一个线程持有写锁/进入lock块，但它们不能直接互相替代，核心差异在定位、复杂度和性能上：

代码对比 #

常规lock写法：

lock (lockObj) {  
  // 执行排他操作  
}

ReaderWriterLock写锁的正确写法（必须加异常保护）：

readerWriterLock.AcquireWriterLock(Timeout.Infinite);  
try
{
  // 执行排他操作  
}
finally
{
  readerWriterLock.ReleaseWriterLock();
}

注意：如果直接写AcquireWriterLock()后不包裹try-finally，一旦代码抛异常，锁会无法释放，大概率导致死锁——这也是和lock的关键区别之一，lock是语法糖，编译后自动生成try-finally逻辑，无需手动处理。

核心差异点 #

• 使用复杂度：lock省心，自动处理锁释放；ReaderWriterLock写锁必须手动维护释放逻辑，稍不注意就出问题。
• 性能开销：lock基于Monitor实现，无竞争时是轻量级锁，开销极小；ReaderWriterLock要维护读写线程的状态，即使只用写锁，整体开销也比lock大，没必要为了排他锁额外承担这部分成本。
• 设计定位：ReaderWriterLock的核心价值是读写分离——支持多个线程同时读，只有写的时候才排他。如果只用它的写锁，完全浪费了它的设计初衷，不如直接用更简单的lock。

选型建议 #

• 只是需要简单的排他同步，直接用lock，省心又高效。
• 如果是读多写少的场景（大部分线程读，偶尔写），适合用ReaderWriterLock（更推荐.NET后续推出的ReaderWriterLockSlim，性能比旧版好很多），此时写锁配合读锁使用，才能发挥它的优势。

内容的提问来源于stack exchange，提问作者gaacode