arraypool.shared 并非线程安全的全局缓存，仅归还操作线程安全；租出数组须由使用者严格控制生命周期，禁止跨线程共享、异步延续中误用或静态复用，且必须显式归还、避免重复或遗漏。
ArrayPool 不是线程安全的“全局缓存”
很多人误以为 ArrayPool<t>.Shared</t> 是个开箱即用、随便取随便还的线程安全池，结果在高并发下出现 IndexOutOfRangeException、数组内容被污染、甚至 ObjectDisposedException。根本原因：它只保证「归还操作本身是线程安全的」，但不保证「同一块数组被多个线程同时读写」的安全性。
关键点在于：你从池里借出的数组，生命周期和使用范围必须由你自己严格控制——不能跨线程共享引用，不能在异步延续中继续使用（除非明确同步上下文），更不能把它塞进静态集合里反复复用。
- 错误做法：
var array = ArrayPool<byte>.Shared.Rent(1024); // 在 Task.Run 里租，却在另一个线程里写
- 正确边界：租、用、还，三者尽量在同一个同步上下文或明确的异步作用域内完成
- 特别注意
await后续代码——如果中间有 await，且后续还要用该数组，必须确保没有其他线程可能正在访问它
租借后必须显式归还，且不能重复归还
忘记归还会导致池内可用数组持续减少，最终退化为每次都 new 数组；重复归还（比如 try/finally 里 double Rent + double Return）会触发 ArgumentException: The array was already returned to the pool.。这不是理论风险，高并发下极易因异常分支或逻辑重入触发。
最稳妥的模式是用 using 块配合自定义 IDisposable 包装器，或者严格遵循 try/finally：
byte[] buffer = null;
try
{
buffer = ArrayPool<byte>.Shared.Rent(4096);
// ... use buffer
}
finally
{
if (buffer != null)
ArrayPool<byte>.Shared.Return(buffer);
}
- 不要依赖 GC 或 finalizer 清理——ArrayPool 不接管内存生命周期
- 归还时传
clearArray: true只在敏感场景（如密码、token）需要，但会带来额外开销；普通业务数据建议设为false（默认值） - 归还大小超过租借大小的数组会被静默忽略（不报错但不回收），所以务必确保
Return的是原租借对象
避免在 hot path 中频繁 Rent/Return 小数组
虽然 ArrayPool 减少了 GC 压力，但它本身也有开销：内部用锁+数组桶管理，小尺寸（如 int[4] 这种固定小结构，直接栈分配（stackalloc）或对象池（MemoryPool<t></t>）反而更高效。
推荐策略：
- 租借阈值建议 ≥ 256 字节，且生命周期 > 几微秒
- 对固定长度小结构，优先考虑
Span<t></t>+stackalloc（需unsafe上下文） - 若需异步流式处理，改用
MemoryPool<t>.Shared</t>，它对Memory<t></t>和IMemoryOwner<t></t>的抽象更适配现代异步 I/O 场景 - 监控池状态：可通过反射读取
ArrayPool<t>.Shared</t>内部桶计数（非公开 API），或用dotnet-trace观察GCHeapAlloc和ArrayPoolRent事件比例
自定义 ArrayPool 时别忽略 maxArrayLength 和 pooledArrayCount
ArrayPool<t>.Create()</t> 允许指定 maxArrayLength 和 pooledArrayCount，但这两个参数不是越大越好。前者影响池内桶划分粒度，后者决定每档大小最多缓存多少数组。
典型误配：
- 把
maxArrayLength设成int.MaxValue→ 池内部会创建大量空桶，浪费内存且查找变慢 - 把
pooledArrayCount设得过高（如 10000）→ 占用大量常驻内存，却极少被用满，实际降低缓存命中率 - 未按业务数组分布建模：比如 90% 请求用 8KB 数组，10% 用 64KB，那么应分两档池，而不是统一用 64KB 池服务所有请求
建议先用 ArrayPool<t>.Shared</t> 跑压测，通过 dotnet-counters --process-id <pid> monitor --counters System.Runtime</pid> 查看 ArrayPool.Rent / Return 频次和失败率，再针对性定制。
真正难的不是调用 API，而是界定「哪段内存该进池、何时进、用完立刻还、还给谁」——这四个问题没想清楚，池就只是换个方式制造 bug。
