FileStream 不可池化，强行复用会引发 ObjectDisposedException 或句柄冲突；应优先使用异步文件操作或自定义流封装，而非尝试池化 FileStream。
FileStream 不能池化，强行复用会出错
直接说结论：FileStream 不是线程安全的，内部持有操作系统句柄和缓冲区状态，一旦关闭或 Dispose，句柄即释放；若试图“重置”后重复使用（比如调用 Seek(0, SeekOrigin.Begin) 再写），大概率触发 ObjectDisposedException 或底层句柄冲突。.NET 官方从未提供 FileStream 池化 API，所有手动池化方案（如 ObjectPool<filestream></filestream>）在真实负载下极易崩溃或数据错乱。
常见错误现象包括：写入内容被截断、读取到旧缓存数据、IOException: The handle is invalid、并发时 System.ArgumentException: Stream was not readable。
- 不要把
FileStream放进ObjectPool<t></t>—— 即使你控制了Reset()行为，也无法安全重置内核句柄 - 高频小文件场景，优先考虑异步 +
FileOptions.Asynchronous | FileOptions.SequentialScan，比池化更有效 - 真正需要复用的是「打开成本高」的场景（如网络映射驱动器、加密容器），此时应封装成自定义流（如
ReusableEncryptedStream），而非复用FileStream
MemoryStream 可以池化，但要注意容量策略
MemoryStream 是纯托管对象，没有非托管资源，适合池化；.NET Core 2.1+ 内置了 ArrayPool<byte>.Shared</byte>，而 MemoryStream 的构造函数支持传入外部数组，这是池化的关键路径。
问题在于：池化后如果每次分配大小不一，容易造成内存浪费或频繁扩容。比如池中返回一块 8KB 数组，但你只写入 100 字节，后续又需要 64KB —— 若没处理好，就会退化成普通 new。
- 用
new MemoryStream(ArrayPool<byte>.Shared.Rent(capacity), writable: true)</byte>创建可复用实例 - 写完必须调用
stream.TryGetBuffer(out ArraySegment<byte> buffer)</byte>获取实际使用的长度，再ArrayPool<byte>.Shared.Return(buffer.Array)</byte> - 避免无脑 Rent 大数组：按业务常见尺寸分档（如 4KB / 64KB / 1MB），或用
Math.Min(Math.Max(expectedSize, 4096), 1024 * 1024)限幅 - 注意
MemoryStream.GetBuffer()返回整个租借数组，不是有效数据长度 —— 错用会导致越界或泄露脏数据
替代方案：用 Pipelines + IBufferWriter 减少中间拷贝
如果你池化 MemoryStream 是为了拼接日志、序列化消息、构建 HTTP body，那本质问题是「多次 Write 导致 byte[] 频繁分配」。这种场景下，System.IO.Pipelines 提供了更底层、零拷贝的流式写入能力，比池化 MemoryStream 更彻底地消除 GC 压力。
典型误用是：先写进 MemoryStream，再 ToArray() 发送 —— 这等于白池化，因为 ToArray() 又分配了一次。
- 用
Pipe的Writer直接写入，最后FlushAsync()推送到目标（socket / file / memory） - 配合
IBufferWriter<byte></byte>实现自定义序列化器，绕过MemoryStream中转 - 注意
Pipe默认使用MemoryPool<byte>.Shared</byte>，它比ArrayPool更适合流式场景（支持分段、自动增长） - 调试时留意
PipeReader.AdvanceTo()调用是否及时，否则内存不会归还池子
ObjectPool 的唯一可行边界：只池化“只读且不 Close”的句柄
极少数场景下，比如长期监控某个只读设备文件（/dev/input/event0 on Linux via WSL，或 Windows 上的命名管道客户端），且确认该句柄永不关闭、不跨线程共享、不 Seek 回退，才可能考虑池化裸 SafeFileHandle + 自定义流包装器。
但这已不属于标准 FileStream 使用范畴，而是 P/Invoke 层面的资源管理。此时池化的是 SafeFileHandle，不是 FileStream 实例本身。
- 必须确保所有线程对同一句柄的读写操作是串行的（加锁 or 用
ConcurrentQueue控制访问） - 禁止调用任何会触发
Dispose或Close()的方法（包括FileStream析构函数） - Windows 上需用
CreateFile打开时指定FILE_FLAG_NO_BUFFERING和FILE_SHARE_READ，否则池化无意义 - 这种做法兼容性差、调试困难，仅建议在性能压测确认 FileStream 创建是瓶颈、且其他优化无效时尝试
事情说清了就结束。真正影响 GC 的往往不是流对象本身，而是背后反复分配的 buffer 数组 —— 把注意力放在 ArrayPool 和 MemoryPool 的合理尺寸控制上，比纠结 “池化 FileStream” 实在得多。
