.NET Core应用内存持续增长：已正确释放仍未缓解

兄弟，我太懂你这种看着内存飙到3-5GB降不下来，对比C的表现直接懵圈的感觉了！结合你描述的场景，核心原因其实是**.NET GC的设计逻辑和C手动内存管理本质上的差异**，我给你拆解一下：

1. .NET GC是“惰性”的，不会即时回收无引用对象 #

和C++里delete/free就立刻释放内存不同，.NET的垃圾回收器是基于内存压力触发的，它的首要目标是保证程序的吞吐量，而不是即时释放每一块无用内存。

• CLR会给不同代的内存（Gen0、Gen1、Gen2）设置回收阈值，只有当内存占用达到阈值，或者程序进入空闲状态但内存压力足够大时，才会自动触发回收。
• 你说工具闲置15分钟内存还没降，说明此时内存占用还没达到CLR触发自动回收的阈值——毕竟3-5GB对于现代机器来说，可能还没让CLR觉得“内存不够用了，得清理”。而手动调用GC.Collect()是强制触发全代回收，不管阈值到没到，所以立刻就把无用内存清掉了。

2. 大对象堆（LOH）可能在“拖后腿” #

你提到内存里保留最多500个byte[]和string，如果这些对象的大小超过85KB，就会被分配到**大对象堆（LOH）**里。LOH的回收逻辑和普通堆不一样：

• LOH默认不会像Gen0/Gen1那样频繁回收，而且在Gen2回收时也不一定会进行内存压缩（避免大对象移动带来的性能开销）。
• 即使这些大对象已经失去引用，只要没触发LOH的回收条件（比如LOH内存占用达到阈值），它们就会一直占着内存。手动GC.Collect()会强制清理LOH，所以内存会瞬间降到正常水平。

3. 你代码里的“释放”和GC眼里的“可回收”不是一回事 #

你说已经正确处理了WebRequests、Responses、Streams，输出直接写文件没存内存，工作单元也失去引用——这只是让对象变成了“可回收”状态，但GC什么时候回收完全由CLR决定，不是你把引用置空就立刻释放。

而C++里你手动调用delete，操作系统会立刻回收内存，两者的内存管理模型完全不同，不能直接对比“即时释放”的表现。

几个可以验证/优化的方向 #

• 用工具排查内存细节：用Visual Studio的内存诊断工具或者dotMemory，看看内存里到底是哪些对象在占空间，是不是LOH里的大对象没被回收。
• 按需手动触发GC：如果你的爬虫是按批次处理任务，可以在每批任务结束后（比如处理完1000条数据），调用一次GC.Collect(2, GCCollectionMode.Forced)，但别频繁调用——毕竟GC回收有性能开销，平衡好吞吐量和内存占用。
• 优化大对象处理：如果业务允许，把超过85KB的byte[]拆成小块，避免进入LOH；或者用ArrayPool<byte>复用数组，减少大对象的分配次数。

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