内存分配时的线程争用：C#单线程为何比多线程更快？

这个现象其实挺典型的，核心原因在于CLR内存分配的线程本地缓存机制和多线程下的锁竞争，再加上Parallel本身的调度开销，共同导致了多线程版本的性能不如单线程。下面我一步步拆解：

1. 小对象分配的底层逻辑：TLA与锁竞争 #

CLR的小对象堆（SOH，用于分配小于85KB的对象）为每个线程提供了线程本地分配缓存（TLA，Thread Local Allocator）——这是一块线程专属的内存区域，在TLA有剩余空间时，线程分配小对象是完全无锁的，速度极快。

但你的测试中，每个CreateList()要创建20000个long[4]（每个占32字节，属于小对象），重复1000次意味着总分配量极大。单线程时，它可以持续利用自己的TLA，只有当TLA耗尽时才需要去全局SOH申请新的内存块，锁竞争的场景极少。

而多线程版本中，多个线程同时在分配小对象，它们的TLA会快速耗尽，然后都去竞争全局SOH的分配锁——这种锁等待的开销是非常大的，远远超过了多线程并行带来的潜在收益，直接导致总耗时增加。

2. Parallel.For的额外开销 #

Parallel.For本身不是免费的：它需要把1000次任务拆分给线程池中的多个线程，涉及线程调度、上下文切换的成本。如果你的任务是CPU密集型，这些开销可以被并行计算的收益抵消，但你的场景是内存分配密集型，并行不仅没带来计算效率的提升，反而因为锁竞争放大了开销。

3. 垃圾回收的间接影响 #

多线程分配会更快地填满小对象堆，导致Gen0 GC的触发频率更高。虽然.NET的GC支持并发回收，但Gen0 GC通常是"stop-the-world"（暂停所有线程）的——多个线程同时分配会让内存占用增长更快，GC暂停的次数变多，进一步拉长了总耗时。而单线程分配时，内存增长是线性的，GC触发的频率更低，暂停的影响也更小。

验证思路 #

如果你想验证这个结论，可以尝试调整测试参数：

• 增大每个CreateList()中对象的数量，让单个任务的内存分配量足够大，这样每个线程的TLA能支撑更久，锁竞争的频率会降低，多线程的性能可能会接近甚至超过单线程。
• 换成大对象（比如大于85KB的数组），大对象堆（LOH）的分配本身就是带锁的，单线程和多线程的锁竞争差异会更小，这时候Parallel的并行优势可能会体现出来。

总结 #

你的测试场景中，多线程的并行收益完全被内存分配的锁竞争和调度开销抵消了，甚至反超。这也是为什么我们常说：内存密集型任务不一定适合多线程，尤其是小对象高频分配的场景。

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