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