arraypool 能显著降低 gc 压力，但必须租后必还、以 buffer.length 判定可用空间而非 minimumlength；rent(1) 浪费资源；shared 池通用，定制长度/隔离/清理策略需 create 新池；return 缺失或过早导致 gc 回升或数据错乱；与 memorystream 混用时须用 trygetbuffer 并归还原始数组。
直接说结论：ArrayPool<t></t> 能显著降低 GC 压力，但前提是「租了必须还」，且不能假设 Rent() 返回的数组长度等于你传入的 minimumLength —— 这两点踩错，性能不升反降，甚至引发数据污染。
为什么 Rent 返回的数组长度经常大于 minimumLength
ArrayPool<t></t> 内部按 2 的幂次预分配多个桶（如 256、512、1024、2048…），当你调用 Rent(800)，它实际会返回一个长度为 1024 的数组。这是为了减少碎片、加快查找速度，不是 bug。
- 你必须用
buffer.Length判断可用空间，而不是硬写buffer[0..800]—— 越界写入不会报错，但可能污染后续租用者的内存 - 如果业务只用前 N 字节，归还时建议设
clearArray = true，否则脏数据可能被下一个人读到（尤其byte[]处理协议头/敏感字段时） - 不要在循环里反复
Rent(1)：池中最小桶通常是 256，Rent(1)和Rent(256)拿到的几乎一样大，纯属浪费
Shared 池够用吗？什么情况下必须 Create 自定义池
ArrayPool<t>.Shared</t> 是进程级静态单例，适合大多数通用场景；但遇到以下情况，ArrayPool<t>.Create()</t> 才是正确选择：
- 需要控制最大数组长度（比如你永远不需要 > 64KB 的缓冲区，可设
maxArrayLength: 65536防止池内囤积巨型数组） - 要隔离不同模块的内存使用（如日志模块和网络模块共用 Shared 池，日志突发写入大量小数组，可能挤占网络模块急需的大缓冲区）
- 需要定制清理策略（
clearMode参数在Create()时可指定，默认是ArrayClearMode.Always，但有些场景可设为Never省掉清零开销）
注意：ArrayPool<t>.Create()</t> 创建的是独立实例，不共享任何内部桶 —— 它不是“子池”，而是全新的一套管理逻辑。
Return 不调用或乱调用的典型后果
忘记 Return() 或在错误时机调用（比如异步任务未完成就归还），会导致两类问题：
-
Return()缺失 → 池中可用数组持续减少 → 后续Rent()被迫 new 新数组 → GC 压力回升，且池化失效 - 提前
Return()（如在Task里写完 buffer 就还，但外部还在读）→ 归还的数组可能被池立刻复用 → 两个逻辑同时操作同一块内存 → 数据错乱、协议解析失败、偶发IndexOutOfRangeException - 多线程并发写同一块租用数组，又没加锁 → 即使
Return()正确，内容也已损坏；ArrayPool<t></t>本身线程安全，但数组内容不安全
和 MemoryStream 池化混用时的关键约束
很多项目用 ArrayPool<byte>.Shared</byte> 配合 MemoryStream 实现缓冲复用，但容易忽略三点：
-
MemoryStream构造时传入租来的byte[]，但调用ToArray()会触发拷贝并丢弃原数组 → 必须用TryGetBuffer(out ArraySegment<byte> seg)</byte>获取底层引用 - 归还时必须用
seg.Array（即原始租借数组），不能用stream.GetBuffer()—— 后者返回的是整个底层数组，而stream.Length可能远小于它，直接还回去会把未使用部分也释放，破坏池容量统计 - 若
MemoryStream写入超过租借数组长度，它会自动扩容（new 新数组），此时旧数组已归还，新数组不在池里 → 必须限制初始容量或监控Capacity是否突增
真正难的不是“怎么租”，而是“什么时候还”和“还哪一块”——尤其在异步链路或异常分支里，try/finally 或 using 之外的路径最容易漏掉 Return()。
