ArrayPool比new T[n]更适合高并发场景，因其通过Rent/Return复用数组减少GC压力；但需严格配对调用且归还大小须匹配桶容量，否则静默失效。
ArrayPool 为什么比 new T[n] 更适合高并发场景
因为 ArrayPool 复用内存块，避免频繁触发 GC；而 new T[n] 每次都分配新数组，在高并发下会快速堆积大量短期存活的中大型数组（尤其是 byte[]、int[]），导致 Gen 0 频繁回收，甚至诱发 Gen 1/2 收集，明显拖慢吞吐。
实际压测中，当每秒分配上万次 4KB–64KB 数组时，ArrayPool 可降低 GC 时间 70%+，但前提是必须 及时归还——漏调 Return() 会导致池子“饿死”，后续 Rent() 被迫退化为 new，反而更糟。
- 只对中等大小（约 1KB–1MB）、生命周期短（毫秒级）的数组收益最大；太小（如
int[4]）用栈变量或 Span 更合适，太大（如 >2MB）池子默认不缓存（受maxArrayLength限制） -
ArrayPool可定制池子行为，比如设置.Create(minLength, maxLength) maxArraysPerBucket = 50防止单个桶无限膨胀 - 归还时传
clearArray: true可清零内容（防敏感数据残留），但有性能开销，非必要不启用
自定义对象池（ObjectPool）和 ArrayPool 的关键区别
ObjectPool（来自 Microsoft.Extensions.ObjectPool）适用于任意引用类型对象复用，而 ArrayPool 专用于数组。两者底层都维护链表或栈式缓存，但 ObjectPool 必须提供 IPooledObjectPolicy 来控制创建、验证、清理逻辑，灵活性更高，也更容易出错。
常见误用是把带状态的对象（如未重置字段的 HttpRequestContext）直接塞进池子，下次取出时残留旧状态引发 bug。
- 必须实现
IPooledObjectPolicy和.Create() IPooledObjectPolicy，后者要负责重置所有可变字段（如.Return(T obj) obj.Reset()） - 池子容量默认无上限，需通过
MaximumRetained限制缓存数量，否则内存持续增长 - 不要在
Return()中抛异常，否则对象会被丢弃，池子缓慢泄漏
高并发下 ArrayPool.Return() 调用失败的典型表现
最常被忽略的是：当归还的数组长度超过池子当前桶支持的最大长度（例如池子按 1024、2048、4096 分桶，却归还了 5000 字节的 byte[]），Return() 会静默失败——数组直接被 GC 回收，池子不报错也不警告。
这会导致你以为“用了池子就万事大吉”，实则部分请求仍在走 new 路径，压测时 GC 峰值忽高忽低，难以定位。
- 用
ArrayPool查看当前池最大支持长度（.NET 6+ 默认 1MB）.Shared.GetMaxSize() - 租用前先估算所需大小，避免跨桶；或用
ArrayPool扩容.Create(maxArrayLength: 1024 * 1024 * 2) - 开启
DOTNET_gcServer=1+DOTNET_gcConcurrent=1确保服务端 GC 行为稳定，避免工作站 GC 在高并发下频繁暂停
一个安全的 ArrayPool 使用模板（C#）
核心原则：租用 → 使用 → 归还，三步必须成对出现，且归还必须放在 finally 或 using 中。以下是最小可靠模式：
public static async Task ProcessRequest(Stream input)
{
byte[] buffer = ArrayPool<byte>.Shared.Rent(8192);
try
{
int bytesRead = await input.ReadAsync(buffer, CancellationToken.None);
// ... 处理 buffer 数据
}
finally
{
ArrayPool<byte>.Shared.Return(buffer);
}
}</byte></byte>
注意：不要把 buffer 存到类字段、闭包或异步状态机里——归还后内存可能已被复用，再读就是脏数据。如果必须跨 await 使用，要么改用 Memory + ToArray()（代价是复制），要么改用对象池管理整个处理上下文。
真正难的不是写对这几行代码，而是确保整个调用链（包括所有异常分支、取消路径、嵌套异步）都覆盖归还逻辑。漏一次，就可能让池子在高负载下逐渐失效。
