多线程反序列化受GC瓶颈制约，如何优化CPU利用率？

针对你遇到的多线程反序列化时GC频繁导致CPU利用率偏低的问题，以下是具体的优化方案：

一、消除隐性对象分配 #

• 预分配集合容量：反序列化中用到List、Dictionary等集合时，提前计算好所需的精确容量并初始化，彻底避免扩容时的数组重新分配与拷贝。比如如果知道要反序列化100个元素，就用new List<T>(100)而非默认构造。
• 替换高频分配类型：用Span<byte>/ReadOnlySpan<byte>处理字节数据，避免中间字符串或数组的临时分配；字符串拼接用预分配容量的StringBuilder，不要直接用+运算符；数值解析优先用Utf8Parser而非Convert类，减少隐性对象生成。
• 杜绝装箱操作：检查反序列化逻辑中是否存在值类型（如int、DateTime）转引用类型的装箱，改用泛型方法或值类型容器存储，避免堆上的临时装箱对象。

二、优化GC行为，降低暂停影响 #

• 启用Server GC：在.NET环境下，将GC模式切换为Server GC（服务器GC），它会为每个CPU核心分配独立的堆分区，采用多线程回收策略，大幅减少全局GC暂停时间。可通过配置文件启用：

  <!-- app.config/web.config 中添加 -->
  <configuration>
    <runtime>
      <gcServer enabled="true"/>
    </runtime>
  </configuration>
  

• 对象/数组池化复用：使用ObjectPool<T>（来自Microsoft.Extensions.ObjectPool）复用反序列化过程中的常用对象（如自定义数据对象、临时容器），或用ArrayPool<T>复用数组，避免频繁创建与销毁对象触发GC。比如每个线程持有ThreadLocal的对象池实例，独立复用。
• 控制对象代龄与大对象堆：尽量让分配的对象留在Gen0（小对象），避免大对象（>85KB）分配到大对象堆（LOH）——LOH回收暂停时间更长。如果必须处理大数组，用ArrayPool<byte>获取复用的大数组，用完归还。

三、改造反序列化为无/低分配模式 #

• 自定义无分配反序列化逻辑：放弃依赖默认序列化框架（如Json.NET、System.Text.Json的默认模式），手动基于Span<byte>解析字节数组。比如直接读取字节解析数值、用ReadOnlySpan<char>处理字符串段，全程避免堆上对象分配。
• 用结构体替代类存储数据：如果数据结构的复杂度允许，将反序列化后的目标对象改为结构体（值类型），分配在栈或栈分配的Span中，彻底避开堆分配。注意结构体大小不宜过大（建议小于1MB），防止栈溢出。

四、调整并行处理策略 #

• 动态控制线程数量：不要固定用满12核，可根据GC的实时占用率动态调整线程数。比如当GC占用超过30%时，减少2-3个工作线程，降低分配压力；当GC压力缓解后再恢复线程数。
• 分批处理任务：将100个文件分成若干批次（比如每批10个），处理完一批后等待一次Gen0回收（可调用GC.Collect(0, GCCollectionMode.Optimized)），再处理下一批，避免持续的高分配导致GC频繁触发。

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