c# 高并发下 ArrayPool 的正确使用姿势

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。