You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

C#中MemoryStream引发内存不足异常问题(已解决)

问题场景

我有一个部署在Cloud Foundry(分配4GB内存)上的.NET Core应用,运行以下克隆对象的代码时抛出内存不足异常。这段代码在批量作业中调用,循环遍历对象列表并克隆每个对象,无法定位具体是哪个记录触发的问题。

已知信息:

  • 确认运行在64位系统(Environment.Is64BitOperatingSystem返回true)
  • 单个对象的JSON(从MongoDB导出)大小仅1MB,但需要为该对象创建超过7000个克隆
  • 部分对象体积较大,但远未达到4GB内存上限
  • 了解到MemoryStream会通过反复释放、重新分配内存来匹配流的最终大小,但未找到针对性解决方案

触发异常的代码

IFormatter frm = new BinaryFormatter();
Stream sm = new MemoryStream();
using (sm)
{
    frm.Serialize(sm, myobj);
    sm.Seek(0, SeekOrigin.Begin);
    return (T)frm.Deserialize(sm);
}
问题分析

这段代码通过BinaryFormatter序列化+反序列化实现对象克隆,每次克隆都会:

  1. 创建MemoryStream存储序列化后的字节数据
  2. 序列化过程中MemoryStream会多次扩容,每次扩容都会分配新内存块,旧内存块需等待GC回收
  3. 批量克隆7000个对象时,短时间内会产生大量临时内存分配,加上GC回收延迟,导致内存占用急剧上升,最终触发OOM
解决方案

优化业务逻辑,避免不必要的对象克隆是唯一可行的解决途径。

可尝试的优化方向:

  • 调整流程,直接复用原对象而非创建克隆
  • 针对只读场景,使用对象共享机制替代复制操作
  • 若必须复制对象,改用更高效的克隆方式(如手动实现浅克隆/深克隆方法,规避序列化带来的额外内存开销)

内容的提问来源于stack exchange,提问作者Anil

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.08.21 05:06:28