多线程处理独立文件时单线程性能骤降原因排查

问题背景 #

我有16个彼此独立的数据文件需要读取并处理，处理代码片段如下：

int threadCount = 1;
ConcurrentBag<SomeClass> items = new ConcurrentBag<SomeClass>();

Parallel.For(0, threadCount, i =>
{
     string[] itemsInfo = File.ReadAllLines("itemInfo" + i + ".txt");
     int index = 0;
     Console.WriteLine("Loading items...");
     List<SomeClass> threadItems = new List<SomeClass>();
     while (itemsInfo[index] != "<!---ITEMS END---!>")
     {
           SomeClass item = new SomeClass();
           index = item.FromString(itemsInfo, index);
           threadItems.Add(item);

           if (i == 0)
           {
              Console.WriteLine("Reading " + item.Id);
           }
     }

     foreach (SomeClass item in threadItems)
     {
          items.Add(item);
     }
});

关键细节 #

• SomeClass.FromString仅执行纯字符串解析，仅依赖输入字符串内部数据
• 单线程（threadCount=1）时每秒处理约20个条目；16线程（对应CPU16虚拟核心）时每秒仅处理约1个条目
• 测速时所有线程均处于while循环阶段，内存未被占满
• 线程数在1-16范围内时，线程数量越多，首个线程的处理速度越慢

可能的原因排查 #

1. 磁盘IO竞争瓶颈 #

如果所有文件存储在同一机械硬盘上，多线程同时发起读请求会导致磁盘磁头频繁切换，将原本的顺序IO变成大量随机IO，直接拉低磁盘效率。机械硬盘的随机IO性能远低于顺序IO，16线程并发读的开销会远超单线程顺序读。即使是SSD，并发读取多个小文件也可能导致IO带宽被分摊，引发性能下降。

2. Console.WriteLine的同步阻塞 #

Console类的输出操作底层是线程安全的同步实现（依赖内部锁）。代码中只有线程0会执行Console.WriteLine("Reading " + item.Id)，但频繁的锁获取/释放会拖慢线程0的处理速度——尤其是单线程每秒输出20次时，锁竞争会成为明显的性能开销。可以临时注释这行代码测试，若性能回升则可确认此问题。

3. 线程调度与上下文切换开销 #

Parallel.For默认使用TaskScheduler调度线程，当设置threadCount=16时，若FromString方法本身执行时间较短（单线程每条约50ms），线程上下文切换的开销会占比极高，直接抵消多线程的优势。可以尝试用Task.Run手动创建16个独立任务，或调整ParallelOptions.MaxDegreeOfParallelism，观察性能变化。

4. CPU缓存失效（伪共享/缓存颠簸） #

如果SomeClass存在静态字段被多线程读写，或类成员变量的内存布局导致伪共享（多个线程操作的变量落在同一CPU缓存行），会引发CPU缓存频繁失效，需要反复从主存加载数据，大幅降低处理速度。可检查SomeClass的实现，或通过调整成员布局（如插入填充字节）避免伪共享。

5. 系统级资源限制 #

系统的文件句柄数、磁盘IO队列长度等存在上限，16个线程同时打开文件可能触发限流机制，导致每个线程的读操作被延迟。可通过系统性能监视器（Windows任务管理器-磁盘页、Linux的iostat）查看磁盘使用率、IO队列长度等指标，确认是否出现IO饱和。

6. ConcurrentBag的隐性竞争 #

虽然每个线程先将数据存入本地threadItems再批量添加到ConcurrentBag，但如果threadItems数量极大，批量Add时仍会产生锁竞争。可临时注释掉添加到ConcurrentBag的代码，仅保留解析逻辑，若性能恢复则可排除此因素。

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