ArrayPool仅在数组生命周期短、尺寸固定、高频调用三条件同时满足时才有效；否则易致内存泄漏、GC压力上升及性能下降。
直接说结论：ArrayPool<t></t> 不是“用了就快”，而是“用错就慢甚至更卡”。它只在特定场景下有效，且必须配对调用 Rent 和 Return，否则内存不归还、池失效、GC压力反而上升。
什么时候该用 ArrayPool？看三个硬指标
别凭感觉——只在同时满足以下条件时才考虑 ArrayPool<t></t>：
- 数组生命周期短（毫秒级，比如单次 HTTP 请求处理、一次序列化/反序列化）
- 数组尺寸相对固定（比如总是租
1024或8192字节缓冲区） - 高频调用（每秒数百次以上），且堆上频繁分配同尺寸数组（
new byte[1024]出现在 hot path 中）
反例：每次租 new byte[size] 且 size 随机波动（如 100~65536），池里大量碎片桶无法复用；或数组存活时间跨多个异步 await（可能被 GC 提前回收或归还失败）。
ArrayPool.Shared 的隐藏行为与坑点
ArrayPool<byte>.Shared</byte> 看似开箱即用，但内部策略容易误判：
- 它按 2 的幂预分配桶（如 128、256、512、1024、2048…），你
Rent(1000)实际拿到的是1024数组，多占 24 字节不算啥，但Rent(1025)就跳到2048，浪费翻倍 - 归还时若数组被修改过长度（如
Array.Resize）、或传入非原始租借对象（比如子数组buffer.AsSpan(0, 512).ToArray()），Return会静默失败，不抛异常也不归池 - 并发高时，
Shared内部锁竞争明显，实测 QPS 超 5k 后吞吐增长趋缓，此时应改用自定义池 +ArrayPool.Create指定桶数量和最大数组尺寸
示例：避免踩 resize 坑
var pool = ArrayPool<byte>.Shared; var buffer = pool.Rent(1024); // ✅ 正确：直接操作 buffer，保持原长度 Process(buffer, length: 800); pool.Return(buffer); // 归还成功 <p>// ❌ 错误：Resize 后 buffer 已不是池中原始引用 Array.Resize(ref buffer, 2048); // 新数组！旧 buffer 仍占用但未归还 pool.Return(buffer); // 实际归还的是新数组，旧的 leak 了
PooledList 是 ArrayPool 的友好封装，但 Dispose 必须显式触发
PooledList<T>（来自 Collections.Pooled）本质是把 ArrayPool<T> 封装进集合 API，但它不是“自动管理”——Dispose() 不调，数组就不还。
- 必须用
using语句块包裹，或手动list.Dispose()，否则内部数组永远滞留，池迅速耗尽 - 不建议在 long-running 方法中反复 new PooledList —— 它的池化收益依赖快速归还，延迟释放等同于没池
- 如果只是临时存几个值（≤ 4），直接用栈变量或内联数组（
[InlineArray(4)] struct SmallList { ... }）比 PooledList 更轻量
示例：正确使用模式
using var list = new PooledList<int>();
list.Add(1);
list.Add(2);
// ... 处理逻辑
foreach (var x in list) { /* ... */ }
// ✅ using 结束时自动调用 Dispose()，数组归还池
ArrayPool 不是万能解药：替代方案优先级要排清
遇到 GC 压力，先问自己：这数组真得上堆吗？
- 小而固定（≤ 256 字节）：优先
stackalloc或内联数组（[InlineArray(N)]），零 GC 开销 - 需跨 await 生命周期：必须用
MemoryPool<T>.Shared.Rent()+using，Span<T>不能出栈帧 - 大对象（≥ 85KB）：避开
ArrayPool，直接走 LOH 优化路径（如对象复用、分块处理），因为池里根本不会存这么大桶 - 只是 List
频繁扩容？设好初始容量比换 PooledList 更简单有效
最常被忽略的一点：ArrayPool.Return(buffer) 的调用位置必须严格对应租借作用域。异步方法中若在 await 后归还，需确保线程上下文未丢失、buffer 未被重用——否则极易引发数据错乱或 ObjectDisposedException。
