C#多线程性能测试对比：Parallel.For与自定义并行方案分析

测试背景 #

我在i7-10700（8核16线程）、.NET 6及Visual Studio 2022环境下，针对100万大小的数组完成7项C#多线程性能测试：每项测试分别以单线程、Parallel.For、自定义并行方案（按Environment.ProcessorCount分配任务）运行三次，测试用例涵盖：

• 简单写入
• 随机写入
• Date结构体创建
• Date类创建
• 多层查找
• 数组最小值查找
• 缓存行隔离的最小值查找

测试结果显示各方案耗时差异显著，针对以下疑问给出解答：

1. 为何Parallel.For性能表现极差？ #

Parallel.For本身存在调度与任务拆分开销，当单任务粒度太小时，这些开销会远超并行带来的收益。如果测试场景存在大量共享资源竞争，Parallel.For默认的分区策略可能引发频繁线程上下文切换，其内部同步机制（如分区锁）也会带来额外损耗。另外，若未指定ParallelOptions的MaxDegreeOfParallelism，可能导致线程数超过CPU核心数，引发过度调度，进一步拖慢性能。

2. 前两项测试（简单写入、随机写入）仅实现约2倍性能提升，是否有更优优化方式？ #

这两个场景的核心瓶颈是内存带宽：单线程下内存读写已接近硬件带宽上限，多线程并行时多个核心争抢内存总线，无法实现线性性能提升。可从以下方向优化：

• 调整访问模式，比如将随机写入改为按顺序分块写入，提升内存局部性，减少缓存失效
• 用Span<T>或Memory<T>替代普通数组，降低托管内存的额外开销
• 预先分配足够内存空间，避免运行时内存分配竞争；随机写入场景可尝试非阻塞内存分配方式
• 确保以Release模式编译并开启优化，禁用调试器附加，让JIT生成最优代码

3. 第三、四项测试（Date结构体创建、Date类创建）显示堆上对象分配适配多线程不佳，该如何解读？ #

结构体是值类型，默认分配在线程私有栈上，多线程下几乎无竞争；而类对象分配在堆上，虽然.NET有线程本地分配缓存（TLAB），但当TLAB耗尽时，多线程会竞争全局堆分配锁，直接拖慢分配效率。此外，大量堆对象创建会触发更频繁的GC，多线程下GC的暂停与回收操作会带来更大性能波动——GC需要暂停部分或全部线程完成回收，严重影响并行效率。

4. 第五项Lookup测试（多层查找）中多线程实现约4倍单线程性能提升，原因是什么？ #

多层查找属于CPU密集型任务，且内存访问局部性较好，每个线程的查找任务能充分利用CPU缓存，同时几乎无共享资源竞争。这种场景下，按Environment.ProcessorCount分配任务的自定义方案粒度合适，没有过度调度开销，能有效利用多核心并行计算，避开了内存带宽瓶颈，因此获得了接近线性的性能提升。

5. 为何未达理论16倍性能提升，是否存在操作失误或需注意的要点？ #

理论16倍是理想状态，实际几乎不可能实现，核心原因包括：

• 硬件限制：i7-10700是8核16线程（超线程），超线程的两个线程共享物理核心的执行单元与缓存，性能提升约30%-50%，无法实现翻倍
• 任务开销：并行任务的拆分、调度、结果合并都有额外开销，任务粒度越小时，这些开销对性能的抵消越明显
• 内存瓶颈：写入、对象创建等场景受限于内存带宽，多线程无法突破硬件上限
• 隐性竞争：即便无显性共享资源，GC后台回收、JIT编译、系统级资源调度等隐性操作也会引发线程竞争
• 测试误差：三次测试的结果可能受后台进程负载影响，导致性能数据波动

需注意的要点：

• 测试前预热代码，让JIT完成编译，避免首次执行的耗时干扰结果
• 保持测试变量单一，仅改变并行方案，其余条件完全一致
• 增加测试次数，取平均值减少误差
• 尝试将MaxDegreeOfParallelism设置为物理核心数（8）而非逻辑核心数（16），部分场景下物理核心满负载的性能优于超线程

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