在日志写入、文件切片、报表导出这类高频IO场景中，如果每处理一个文件就new一个MemoryStream或FileStream，用完立刻丢弃，垃圾回收器就会持续回收这些短命对象。单个对象看似不大，但每秒成千上万次分配叠加起来，Gen0和Gen1的GC频率会明显上升，进而引发延迟毛刺。池化（Pooling）的思路很简单：对象用完不扔，放回池子里，下次直接复用，从根源上减少分配。
为什么MemoryStream频繁分配会给GC带来压力
MemoryStream内部维护一个byte数组作为缓冲区，而且这个缓冲区是动态增长的。当你不断Write写入数据时，一旦容量不足，它会分配一个约两倍大小的新数组，把旧数据拷贝过去，旧数组随即变成垃圾。一个 MemoryStream从创建、扩容到丢弃，中间可能产生好几个被废弃的中间数组，这些数组在LOH（大对象堆）上分配超过85000字节时，还会触发更昂贵的回收流程。
FileStream的情况略有不同，它本身是非托管资源，靠SafeFileHandle包装，析构终结机制参与其中。虽然FileStream对象本身较小，但频繁打开关闭文件涉及内核句柄操作和终结器队列的压力，同样不是零成本。理解这些细节后就能明白，池化不只是省下new的开销，更重要的是避开了扩容拷贝、终结器排队和GC停顿这些隐形成本。
使用Microsoft.IO.RecyclableMemoryStream现成方案
如果没有特殊需求，直接用社区久经考验的Microsoft.IO.RecyclableMemoryStream库是最稳妥的选择，它被Bing等大型系统使用多年。这个库提供了一个RecyclableMemoryStreamManager，内部用多个池分别管理不同大小的缓冲块，取流时按需拼接，归还时块级复用，彻底避免了传统MemoryStream的扩容拷贝。
首先通过NuGet安装：Install-Package Microsoft.IO.RecyclableMemoryStream，然后建议将Manager声明为单例，整个应用共享一个：
public static class StreamPool
{
// 全局单例，参数依次为最大池块数、大块大小阈值等
public static readonly RecyclableMemoryStreamManager Instance =
new RecyclableMemoryStreamManager(
blockSize: 1024 * 1024, // 每块1MB
largeBufferMultiple: 1024 * 1024,
maximumBufferSize: 128 * 1024 * 1024,
useExponentialLargeBuffer: true);
}
public class FileService
{
public byte[] ReadAndProcess(string path)
{
// 从池中获取流，而不是new MemoryStream()
using (var ms = StreamPool.Instance.GetStream("ReadAndProcess"))
{
using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read))
{
fs.CopyTo(ms);
}
return ms.ToArray();
} // Dispose时自动归还到池中，而非真正释放
}
}
有几个使用要点需要特别注意。第一，必须调用Dispose或使用using，否则流不会归还池中，池就失去了意义。第二，如果拿到了池化流的GetBuffer()返回的内部数组，绝不能在流Dispose后继续访问，因为该数组可能已经借给别人了；需要长期持有数据时用ToArray()拷贝一份。第三，可以在构造函数中传入options对象进行更细粒度配置，比如控制每个大小档位的最大缓存数量，防止池本身无限膨胀占用内存。
基于ObjectPool自定义FileStream池
.NET自带的Microsoft.Extensions.ObjectPool适合池化那些状态可重置的对象。FileStream虽然不能直接复用，但可以包装一层：池化的是封装对象，每次取出时用新的文件路径重新打开句柄，归还时关闭句柄。下面的例子演示了这种模式：
public class PooledFileStream : FileStream
{
internal string OwnerInfo { get; set; }
public PooledFileStream() : base(
Path.GetTempFileName(), // 占位路径，后续重开
FileMode.OpenOrCreate,
FileAccess.ReadWrite,
FileShare.None,
4096,
FileOptions.Asynchronous | FileOptions.DeleteOnClose)
{
}
}
public class FileService
{
private readonly DefaultObjectPool<PooledFileStream> _pool;
public FileService()
{
var policy = new DefaultPooledObjectPolicy<PooledFileStream>();
_pool = new DefaultObjectPool<PooledFileStream>(policy, maximumRetained: 64);
}
public void WriteFile(string path, byte[] data)
{
var stream = _pool.Get();
try
{
stream.SetLength(0); // 重置状态
stream.Position = 0;
stream.Write(data, 0, data.Length);
stream.Flush(true); // 刷盘，保证持久化
}
finally
{
_pool.Return(stream); // 归还，供下次复用
}
}
}
自定义池的核心在于策略设计：Get之后对象的旧状态必须彻底清理，否则会出现数据串扰这类极难排查的bug。对于FileStream，更实用的做法其实是保持文件句柄常开，比如日志场景中一个文件对应一个长期打开的StreamWriter，本质上是池化的极端形式——单实例永久复用。另外要意识到，FileStream池化省的是对象头和句柄创建成本，收益不如MemoryStream池化明显，需结合压测数据决定是否值得引入。
结合ArrayPool处理字节数组与性能验证
很多文件操作链路中，除了流本身，CopyTo过程中用到的临时byte数组也是分配大户。可以借助System.Buffers.ArrayPool<byte>.Shared租借缓冲区，手动搬运数据：
public void CopyWithArrayPool(string srcPath, string dstPath)
{
var buffer = System.Buffers.ArrayPool<byte>.Shared.Rent(81920);
try
{
using (var src = new FileStream(srcPath, FileMode.Open, FileAccess.Read,
FileShare.Read, 4096, FileOptions.Asynchronous | FileOptions.SequentialScan))
using (var dst = new FileStream(dstPath, FileMode.Create, FileAccess.Write,
FileShare.None, 4096, FileOptions.Asynchronous))
{
int read;
while ((read = src.Read(buffer, 0, buffer.Length)) > 0)
{
dst.Write(buffer, 0, read);
}
}
}
finally
{
System.Buffers.ArrayPool<byte>.Shared.Return(buffer);
}
}
优化是否有效，不要凭感觉，要用数据说话。推荐用dotNet count monitor工具或事件计数器观察GC Heap Size、Gen0 GC Count和Allocation Rate三项指标，对比池化前后的差异。典型情况下，引入RecyclableMemoryStream后分配速率可能下降一个数量级，Gen0回收次数大幅减少，P99延迟曲线明显更平稳。也可以在BenchmarkDotNet中跑微基准，关注Memory列的分配字节数变化。
最后提醒两个常见坑：一是池不是越大越好，maximumRetained设置过高会导致内存常驻膨胀，反而挤压其他模块；二是池化与async/await配合时，务必确保流在异步操作完全结束后才归还，否则会出现竞态。只要守住这两条底线，池化就是降低GC压力、稳定服务延迟的有力武器。
C#对象池MemoryStream池化GC压力优化修改时间：2026-09-07 04:42:32