多线程并发写同一个文件这问题看着简单真下起手来能炸出一堆坑。早几年我遇到过这么个场景程序里十几个后台任务同时往一个日志文件里写内容结果文件里出现大量半行乱码、内容互相穿插、甚至直接抛“文件正由另一进程使用”的异常。当时第一反应就是加锁但加了lock之后反而更难受——写日志的吞吐掉得厉害因为所有读操作也得排队等着。后来换了读写锁才终于把并发写文件和线程同步这件事理顺了。这篇文章就围绕这个问题展开为什么多线程写文件需要同步、C#里有哪几种常见的同步方案、读写锁ReaderWriterLockSlim为什么适合这种场景以及怎么用、用什么参数、踩过哪些坑。内容偏向实际落地代码可以直接抄。1. 多线程写文件为什么不能直接开干1.1 一个能复现问题的场景先看一段“想当然”的代码。假设我有3个线程同时往同一个文件里写一段话private static void WriteWithNoSync(int threadId) { string content $线程{threadId}写入: {DateTime.Now:HH:mm:ss.fff} - {new string(*, 50)}; using var fs new FileStream(C:\temp\test.log, FileMode.Append, FileAccess.Write, FileShare.None); var bytes Encoding.UTF8.GetBytes(content Environment.NewLine); fs.Write(bytes, 0, bytes.Length); fs.Flush(); }然后起3个线程同时调用var tasks Enumerable.Range(0, 3) .Select(i Task.Run(() WriteWithNoSync(i))) .ToArray(); Task.WaitAll(tasks);跑几次就会发现结果完全不固定。运气好时三个线程一条条写完文件内容干干净净运气差时直接抛IOException提示文件正在被占用再或者文件里出现那种“线程2技线程0写入:……”的拼接错乱。原因很简单FileStream默认打开文件时如果指定了FileShare.None同一时刻只允许一个句柄持有文件第二个线程打开就会冲突。即使把FileShare.ReadWrite加上多个线程可以同时打开文件但写入位置互相干扰一个线程写到一半另一个线程可能把文件指针挪走了最后写入的数据就交错在一起。fs.Write并不是原子操作它只是“请求”写入一批字节操作系统可能在任意时刻切换线程导致一个线程的写入序列被拆开。所以结论很直接多线程并发写同一个文件必须同步。问题是同步方案怎么选。1.2 线程安全的本质独占与共享理解线程同步先抓一个关键所谓“安全”本质上是在管理资源的访问方式。文件这种共享资源操作有两类读可以并行多个线程同时读同一个文件没问题。写必须独占同一时刻只能有一个线程在改文件内容否则数据就乱。这里有个很微妙的点很多资料没讲透写操作内部也经常包含读操作。比如你要“读取某个配置文件的全部内容再修改其中一行再整体写回”这个过程里两个线程同时进来就可能一个线程读的是旧数据、一个线程读的也是旧数据然后各自把新数据写回去后者覆盖前者更新丢失。这种问题不是锁能单独解决的必须在锁内完成“读-改-写”整个事务。后面写代码的时候我会专门处理这一点。所以选择同步方案时不能只想着“我用个锁把写包起来”要先区分需求如果你的场景只是“一个线程写完另一个线程再写”任何互斥锁都行。如果你有大量“读现有文件内容定期追加/改写”的场景就需要支持读并发、写独占的机制。这正是读写锁的主场。1.3 常见的三种错误尝试先说不建议的方案都是我自己在项目里或帮别人排查时见到的第一用lock (this)或lock (obj)包住整个写操作。这个方案的缺点有两个。一是粒度太粗读文件也被lock挡在外面明明多个线程可以同时安全读却被迫串行二是在异步代码里lock一个Monitor不是awaitable的写异步文件时根本使不上劲。另外lock (this)这种写法在类里极不推荐因为this作为同步对象是Public的外部如果有别的对象也锁同一个实例可能无端变成死锁。第二用Monitor.Enter/Exit手动控制。本质上和lock一样只是给了你TryEnter的能力。如果只是需要超时保护它可以但依然是“所有操作一律互斥”并不符合读写分离的诉求。第三用Mutex或Semaphore。Mutex可以跨进程但性能比Monitor差而且使用不当会频繁触发内核态上下文切换Semaphore适合限流比如限制最多N个线程同时访问但它并不能区分读和写不等于读写锁。这些方案不是说绝对不能用而是放在“多线程写同一个文件”的场景里要么粒度不对要么性能不理想。真正趁手的还得是读写锁。2. C#锁方案选型为什么最终选了ReaderWriterLockSlim2.1 从需求反推读写锁的价值在哪里回到并发写文件的场景仔细分析一下访问模式某些线程在写入文件 → 必须互斥。某些线程在读取文件内容比如读日志尾部、读配置、读缓存 → 可以共享。读与写之间互相排斥 → 不能一边读一边写。读操作在数量上远多于写操作 → 性能优化的空间在“读并发”。如果只用互斥锁读和写全部串行那么就算有30个线程同时读文件也只有一个能进其他29个阻塞。而用读写锁时多个读者可以同时进入临界区只有写者需要独占。在一个“读多写少”的系统里这个区别对吞吐量的影响非常大。我举一个实际数字某次做一个本地数据缓存服务文件里存了大概2万条索引记录。业务侧有几十个请求线程要查这个缓存每几秒才有一个线程在更新缓存。最开始用lock包整个缓存查询更新接口平均响应时间在并发100时飙升到几百毫秒改成ReaderWriterLockSlim后查询线程之间完全不互斥平均响应时间掉到几十毫秒写线程依然安全串行。这个体验差异是很直观的。当然如果你的场景是“所有线程都在写日志几乎没什么读”读写锁就没什么优势甚至因为内部逻辑更复杂性能还略低于简单的lock。所以选型前一定要先看清读写比例。2.2 C#常见同步方案对比我整理了一张对比表方便直观选型方案支持读并发支持跨线程等待支持超时性能特点适用场景lock/Monitor否是手动TryEnter用户态锁短临界区很快简单互斥临界区极短Mutex否是可跨进程是涉及内核切换较重跨进程互斥SemaphoreSlim否是是轻量但无法区分读写限流控制并发数ReaderWriterLockSlim是是是轻量有读写分离读多写少的共享资源ReaderWriterLock是是是老版本较重易死锁不推荐已过时lock 原子操作如Interlocked否部分否极快单变量、计数器等从这张表可以看得出来ReaderWriterLockSlim是.NET 3.5之后推出的、专门替代老版ReaderWriterLock的读写锁实现。它支持三种模式读模式、写模式、可升级读模式后面两种模式配合起来能解决很多“先读后写”的原子性需求。2.3 读写锁的核心设计三种模式的区别ReaderWriterLockSlim里有三个重要的方法组EnterReadLock()/ExitReadLock()进入读模式锁多个线程可以同时持有读锁。EnterWriteLock()/ExitWriteLock()进入写模式锁任何其他读锁或写锁都不能同时存在。EnterUpgradeableReadLock()/ExitUpgradeableReadLock()进入可升级读模式锁它的特点是可以多个线程同时持有“可升级读锁”但它们之间不互斥不过在任意时刻最多只能有一个线程把可升级读锁升级为写锁。为什么要有“可升级读锁”最常见的一个场景就是“先查缓存如果在返回如果不在加载并写入缓存”。如果只用读锁和写锁你会得到这样的代码_rwLock.EnterReadLock(); try { if (cache.TryGet(key, out var value)) { return value; } } finally { _rwLock.ExitReadLock(); } _rwLock.EnterWriteLock(); try { // 重新检查防止别的线程已经写入了 ... } finally { _rwLock.ExitWriteLock(); }这里的问题是从“释放读锁”到“获取写锁”之间可能另一个线程也发现了缓存缺失于是两个线程同时去加载造成重复写入或重复计算。要解决这个问题可以在升级锁内直接升级保证整个“读-写”过程是原子的_rwLock.EnterUpgradeableReadLock(); try { if (cache.TryGet(key, out var value)) { return value; } _rwLock.EnterWriteLock(); try { // 这里可以安全地写入因为升级写锁会阻塞所有其他读者和写者 } finally { _rwLock.ExitWriteLock(); } } finally { _rwLock.ExitUpgradeableReadLock(); }这套机制在写文件场景里的意义在于你可能需要先读取文件当前内容判断是否需要覆盖或追加然后再写入。如果不升级锁判断和写入之间就会有空窗期导致写入覆盖掉别的线程刚写的数据。2.4 选型的两个关键判断点结合上面分析选择读写锁之前问自己两个问题问题一这个共享资源是“读多写少”吗如果你拿不准可以用计数器粗测一下或者直接用简单的lock起步等真出现并发瓶颈再换读写锁。如果一开始就无脑上读写锁代码复杂度会增加收益却不一定显现。问题二写入操作和读取操作是否存在“先读后写”的复合流程如果有就一定要考虑使用EnterUpgradeableReadLock而不是简单地在读锁和写锁之间切换否则可能出现重复写入或数据覆盖。还有一点读写锁不是银弹。它保证的是“同时只有一个写者、读者可以并行”但它不保证“写入顺序”。如果你的业务要求多线程写文件的顺序按照“调用先后顺序”来读写锁做不到你需要引入队列或单调递增序号来实现FIFO。3. 读写锁核心API与关键细节3.1 方法族入门先看ReaderWriterLockSlim最核心的几个属性IsReadLockHeld当前线程是否持有读锁。IsWriteLockHeld当前线程是否持有写锁。IsUpgradeableReadLockHeld当前线程是否持有可升级读锁。RecursionPolicy递归策略支持NoRecursion或SupportsRecursion。CurrentReadCount当前持有读锁的线程数。WaitingReadCount、WaitingWriteCount、WaitingUpgradeCount等待各模式锁的线程数。SpinCount在进入等待队列前自旋尝试获取锁的最大次数。常用方法就是EnterReadLock/ExitReadLock、EnterWriteLock/ExitWriteLock、EnterUpgradeableReadLock/ExitUpgradeableReadLock以及对应的TryEnterReadLock、TryEnterWriteLock、TryEnterUpgradeableReadLock。值得说明的是ReaderWriterLockSlim在构造函数里可以传入LockRecursionPolicy。默认是NoRecursion即同一个线程不能重复进入读锁或写锁。什么意思比如你在持有读锁的线程里又调用EnterReadLock就会抛LockRecursionException。这个设计是为了防止锁递归导致死锁保留默认策略就好千万不要为了省事改成SupportsRecursion这会让锁语义变得非常复杂出问题时极难排查。3.2 超时机制与异常处理很多初学者只写EnterWriteLock()不写TryEnterWriteLock结果在高竞争场景下某个线程等锁等了很久程序看起来就像卡死了。实际项目里我更倾向于使用带超时参数的版本if (_rwLock.TryEnterWriteLock(TimeSpan.FromSeconds(2))) { try { // 写入 } finally { _rwLock.ExitWriteLock(); } } else { // 记录超时日志或者选择排队重试 }注意TryEnterWriteLock返回false不代表写入失败只是说明2秒内没拿到锁。你要根据业务决定是丢弃本次写入、稍后重试还是直接报错。对于日志写入如果丢几条日志无所谓那超时丢弃就很合理如果是关键数据落盘超时后应该记录到备用文件不能静默丢失。这里还要注意异常处理顺序。锁的退出代码一定要放在finally里这样才能保证即使临界区里抛异常锁也会被释放。否则锁会一直持有其他线程全部阻塞程序假死。别看这是基础常识我在代码审查时见过不少把ExitWriteLock写在try里的写法那是在给自己埋雷。3.3 不要在锁内做长时间的IO这条是使用任何锁的通用铁律但在文件读写场景尤其关键。假设你在EnterWriteLock()后直接在锁内执行File.WriteAllText或fs.WriteAsync而且文件很大这个写操作可能要耗时几十毫秒甚至几秒。在这期间所有读线程全部被阻塞系统吞吐量直接归零。这和“用锁保护短临界区”的原则是完全相悖的。我推荐的做法是锁内只做“内存数据的修改和标记”真正的大IO放到锁外。比如string snapshot; _rwLock.EnterReadLock(); try { snapshot _cache.ToString(); } finally { _rwLock.ExitReadLock(); } // 锁外做IO await File.WriteAllTextAsync(_path, snapshot);当然这并不是万能药。上面这种方案存在“快照而写”的间隙在读取快照后、写文件前可能有别的线程修改了缓存导致磁盘上写入的是旧数据。如果你的业务对一致性要求极高可以在写入前再次检查版本号只让最新版本落盘。这就是“版本号读写锁”的组合拳我会在后面的完整代码里演示出来。4. 完整实现用读写锁改造并发写入4.1 先写一个简单的日志写入工具类假设现在要做一个极简的日志写入器多个业务线程同时追加日志要求不能互相覆盖也不能抛文件占用异常。最基础版本是这样的public class SimpleLogWriter { private readonly string _filePath; private readonly ReaderWriterLockSlim _lock new(LockRecursionPolicy.NoRecursion); public SimpleLogWriter(string filePath) { _filePath filePath; } public void Write(string message) { _lock.EnterWriteLock(); try { using var fs new FileStream(_filePath, FileMode.Append, FileAccess.Write, FileShare.Read); var bytes Encoding.UTF8.GetBytes(message Environment.NewLine); fs.Write(bytes, 0, bytes.Length); fs.Flush(); } finally { _lock.ExitWriteLock(); } } }这段代码能解决文件占用和内容交错的问题。写入是串行的FileShare.Read允许其他线程读取这个文件比如日志查看器但FileAccess.Write保证同时只有一个写句柄在追加。不过这个版本有个明显问题每次写入都打开、追加、关闭文件锁的持有时间包含了文件IO的耗时。在高并发下即便是几个毫秒的IO也会让竞争线程排队变长。所以下面我会给出优化版。4.2 一个更实用的批量日志写入器别急着追求“完全异步”之类的高性能方案先从工程角度看问题。日志写入通常能接受“小批量合并”。核心思路是把写入内容先放到内存缓冲队列里当队列达到一定阈值或者经过一定时间后再一次性落盘。这里的关键是缓冲队列本身就是共享资源也必须用锁保护。我用读写锁来保护队列消费者线程用写锁取出所有待写入内容。public class BatchLogWriter { private readonly string _filePath; private readonly ReaderWriterLockSlim _lock new(LockRecursionPolicy.NoRecursion); private readonly Liststring _buffer new(); public BatchLogWriter(string filePath) { _filePath filePath; } public void Write(string message) { _lock.EnterWriteLock(); try { _buffer.Add(message); if (_buffer.Count 100) { FlushBuffer(); } } finally { _lock.ExitWriteLock(); } } public void Flush() { _lock.EnterWriteLock(); try { FlushBuffer(); } finally { _lock.ExitWriteLock(); } } private void FlushBuffer() { if (_buffer.Count 0) return; var lines string.Join(Environment.NewLine, _buffer) Environment.NewLine; _buffer.Clear(); // 注意这里仍然在锁内。真要追求极致可以改成锁外写。 using var fs new FileStream(_filePath, FileMode.Append, FileAccess.Write, FileShare.Read); var bytes Encoding.UTF8.GetBytes(lines); fs.Write(bytes, 0, bytes.Length); fs.Flush(); } }这种设计下批量写入大幅减少了打开文件、系统调用的次数锁的临界区也还包含IO操作但频次低多了。实测下来单线程循环写1000条日志同步写耗时约1.5秒批量写只需约100毫秒差距接近一个数量级。4.3 缓存定时落盘读写锁的另一种打开方式如果你做的不是日志而是一个“内存配置文件”要求多个线程读配置、偶尔有线程更新配置并落盘那么读写锁就发挥出它的真正优势了。这种场景下读操作不需要锁住整个IO流程只需在读取内存对象时加读锁。下面是一个带版本号校验的配置缓存类public class ConfigCacheT where T : class { private readonly ReaderWriterLockSlim _lock new(LockRecursionPolicy.NoRecursion); private readonly string _filePath; private T? _cache; private int _version; public ConfigCache(string filePath) { _filePath filePath; } public T Get() { _lock.EnterReadLock(); try { if (_cache ! null) return _cache; // 这个分支理论上只在第一次发生 // 为了原子性用可升级读锁升级写锁 } finally { _lock.ExitReadLock(); } // 真正的加载放到锁外或升级锁里 _lock.EnterUpgradeableReadLock(); try { if (_cache ! null) return _cache; _lock.EnterWriteLock(); try { var loaded LoadFromFile(); Interlocked.Increment(ref _version); _cache loaded; return _cache; } finally { _lock.ExitWriteLock(); } } finally { _lock.ExitUpgradeableReadLock(); } } public void Update(FuncT, T updateFunc) { _lock.EnterUpgradeableReadLock(); try { var current _cache ?? LoadFromFile(); var newValue updateFunc(current); _lock.EnterWriteLock(); try { _cache newValue; Interlocked.Increment(ref _version); SaveToFile(newValue); } finally { _lock.ExitWriteLock(); } } finally { _lock.ExitUpgradeableReadLock(); } } private T LoadFromFile() { // 读取文件和反序列化 throw new NotImplementedException(); } private void SaveToFile(T value) { var json System.Text.Json.JsonSerializer.Serialize(value); File.WriteAllText(_filePath, json); } }注意这里我用了“可升级读锁写锁”的组合保证两个Reader不会同时更新缓存导致版本丢失。用int和Interlocked在锁内做版本递增即使锁外某个线程判断版本也能看到最新值。4.4 如果文件很多要不要一把锁管所有有些系统会同时操作多个文件比如“按日期拆分日志”“每个业务模块一个日志文件”。这时候新手容易犯的错是给所有文件共用一把读写锁导致不同文件之间也互相阻塞。正确做法是用ConcurrentDictionary维护每把文件对应的读写锁。private readonly ConcurrentDictionarystring, ReaderWriterLockSlim _locks new(); private ReaderWriterLockSlim GetLockForFile(string path) { return _locks.GetOrAdd(path, _ new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion)); }这样做之后不同文件的写入互不干扰相同文件的写入依然保证串行。值得注意的是GetOrAdd并不是完全原子地在所有情况下只创建一次实例但ConcurrentDictionary的这一实现已经足够安全它会在更新期间持有内部锁因此不会出现两个线程各创建一个实例的情况。最后别忘了程序退出前把ReaderWriterLockSlim都Dispose掉虽然它不占用什么系统资源但规范起见还是清理干净。5. 参数调优与性能验证5.1 一个快速基准测试说再多理论不如跑个数字。我用一个简单测试10个线程同时向同一个文件写入每个线程写100次每次写入内容约50字节。测试环境是一台普通的开发机.NET 8。结果大致如下方案耗时备注无锁直接写可能异常有时能写完不可靠性能数据无意义lock包整个写入1200-1600ms所有写都串行包含IOReaderWriterLockSlim包写入1100-1500ms和lock差距不大因为写写本就互斥批量缓冲读写锁150-300ms高频写入时的优选这里有个重要提示在同一时刻所有线程都是写者时读写锁与普通互斥锁性能相当有时还略慢一点点因为原本就有更复杂的等待逻辑。但在“读多写少”场景差距就拉大了。我额外测了“90%读10%写”的情况读写锁方案比lock快了接近4-5倍。所以性能调优的第一步是明确你的场景到底是什么不要为了炫技而选择复杂方案。5.2 调节SpinCount和超时时间SpinCount的默认值是SpinWait次数的上限默认大概是4000次。它在高并发、临界区极短的场景下有用——线程没有立即进入内核态阻塞而是先自旋一小段时间等锁持有者释放。如果锁持有时间通常只有几微秒自旋能显著降低上下文切换开销。我试过在日志批量写入场景里把SpinCount调低到100吞吐变化不大但在一个“内存字典保护”的场景里把SpinCount从默认调高到10000竞争激烈时吞吐提升了约30%。这里面的规律是临界区越短越值得增加自旋次数。超时时间则没有万能值。如果写入任务优先级很高比如业务关键数据落盘超时时间可以设长一些例如5秒如果只是日志超时时间设1秒甚至500毫秒就够超时后走降级路径而不是一直阻塞。5.3 你不该做的“优化”在锁领域最容易翻车的调优是破坏互斥语义。常见的有把写锁改成读锁只是因为写操作内部用了原子变量觉得不需要独占。这是危险的因为原子变量保证的是单个变量的原子性不能保证文件流操作或复合逻辑的原子性。在使用async的代码里用读写锁的同步方法包住整个异步流程。异步方法内部会切换线程锁的持有线程可能在await期间变了导致退出锁时根本不在持有锁的线程上轻则抛异常重则破坏锁状态。如果需要异步等待应使用专门设计的异步锁方案比如基于SemaphoreSlim的异步锁或者确保锁只包同步的短流程。6. 常见问题与排查技巧实录6.1 经典死锁可升级读锁的误用我在帮一个开发者排查问题时见过这样的代码_rwLock.EnterReadLock(); try { // 判断缓存 if (needUpdate) { _rwLock.EnterWriteLock(); // 直接抛异常 } } finally { _rwLock.ExitReadLock(); }这在默认的NoRecursion策略下会抛LockRecursionException。当时那人说“我明明在锁里判了怎么一升级就崩”。原因就是当某线程持有读锁时它不能直接升级为写锁必须先退出读锁再申请写锁或者使用可升级读锁。否则会导致锁递归其他等待写锁的线程无法进入形成死锁风险。正确的处理方式是在进入临界区之前用TryEnterUpgradeableReadLock而不是已经持有读锁后再升级。记住一个原则锁的模式在进入之前就要决定好不要在临界区内临时升级或降级。6.2 写文件乱序与“不完全覆盖”还有一个容易忽略的问题多个线程同写一个文件就算加了锁最终文件内容的“顺序”也无法预测因为哪个线程先进入临界区取决于调度器。如果你要求日志按业务时间排序那需要在写入前给每条日志打上序列号或者使用BlockingCollection之类的队列来维护严格的FIFO顺序。另一种情况是“配置覆盖丢失”。两个线程同时更新配置关键路径都是“读旧值→算出新值→写回”。如果两个线程都用了可升级读锁写锁那么第二个线程会等待第一个线程释放锁之后重新执行“读旧值”逻辑吗不一定。它会等待拿到锁后立刻执行你写在锁里的逻辑你需要在锁内重新读取最新值而不能在锁外缓存旧值。这就是我一次实际踩坑的教训锁外先读了配置锁内直接用旧值更新结果两次更新只保留了一个。6.3 排查工具与实战定位遇到并发写文件的疑难杂症我一般按这个顺序排查打开Procmon或资源监视器看文件句柄冲突。如果是文件占用异常先确认是不是FileShare设置不对。在代码里给每个线程加日志时间戳和线程ID写入内存队列而不是文件避免日志本身干扰。用ThreadPool线程转储或者直接抓进程dump查看哪些线程卡在哪个锁上。ReaderWriterLockSlim会显示成等待状态。如果怀疑是死锁先在try里设置超时超时后主动抛出定位是哪一行的锁没有被释放。观察CurrentReadCount、WaitingWriteCount、WaitingUpgradeCount属性可以快速判断锁竞争是不是比预期严重。这里分享一个独家小技巧我经常在内存里维护一个“锁统计器”每次进入/退出锁时累加计数然后每隔一分钟输出等待次数和超时次数。这个数据比任何性能分析工具都直接——能告诉你是哪个锁、哪个操作在拖垮系统。6.4 快速自查清单最后给一张自查清单当作写代码时的核对表检查项说明是否在finally里释放锁没释放等于死锁锁是否保护了正确的代码块太小则不安全太大则性能差是否区分了读写模式全部用写锁会牺牲并发读是否用了可升级读锁处理“先读后写”避免读锁内升级异常锁内是否包含大文件IO尽量把IO移出临界区每个文件是否有独立的锁避免全局一把锁拖累所有文件是否设置了超时防止无限制等待导致假死是否需要写顺序保证有则需队列读写锁不保证顺序最后分享一点实操心得大概是三年前我在一个数据采集服务里优化过类似问题。当时处理的是多个采集线程把数据写入同一个数据文件同时有个查询线程要实时读取最新数据。最开始也想过用最简单的lock但测试后发现查询响应时间完全不能接受后来改用ReaderWriterLockSlim加批量缓冲查询并发路径直接改成读锁写入走写锁加批量落盘整体稳定性才真正提上来。这个项目里我还学会了另一件事不要追求把锁的粒度写到最小有时候把一批操作合并到一次写锁里反而比频繁加解锁更高效。合理权衡并发和IO比一味炫技更重要。如果你正在面临多线程写文件的困扰建议先从自己的读写比例出发明确场景再选择合适的同步策略。大部分情况下一把ReaderWriterLockSlim加上合理的缓冲已经能应付绝大多数业务需求了。