C#高并发Socket服务字节缓冲区复用，选ArrayPool、MemoryPool还是ObjectPool？

针对你提到的单消息不超过100KB、数千Socket连接的高并发收发场景，三种方案的选型优先级如下：

1. 优先使用ArrayPool<byte>.Shared #

• 这是.NET运行时官方维护的缓冲池实现，已经针对高并发场景做了大量成熟优化：包括分桶管理不同长度的缓冲区、线程本地存储减少锁争抢、自动处理闲置缓冲区回收、大对象堆（LOH）优化等。你场景里的100KB缓冲区大于85000字节阈值，属于大对象，反复new byte[]会导致LOH碎片化，GC回收压力极高，用官方的ArrayPool可以完全避免这个问题。
• 用法极简，无需自行维护池的生命周期：申请时调用var buffer = ArrayPool<byte>.Shared.Rent(102400)，使用完调用ArrayPool<byte>.Shared.Return(buffer)即可，比自己实现ObjectPool省掉了线程安全、扩容、淘汰等大量逻辑的开发和维护成本，也不会出现自定义池常见的内存泄漏、并发争抢问题。
• 注意：Rent返回的数组长度可能大于你申请的长度，实际使用时只需要取业务需要的长度即可；如果有数据安全要求，返回时可以传clearArray: true自动清空缓冲区内容。

2. 适配新版内存API可选择MemoryPool<byte>.Shared #

• MemoryPool本质是对ArrayPool的上层封装，默认底层实现就是用的ArrayPool，性能没有明显差异。它返回的是IMemoryOwner<byte>类型，可以直接拿到Memory<byte>结构，如果你用的是基于Span/Memory的新版Socket异步API（比如Socket.ReceiveAsync(Memory<byte>, ...)），用MemoryPool写出来的代码更简洁，不需要手动处理数组切片，也能降低数组越界的风险。

3. 不建议自行实现固定长度的ObjectPool #

• 自定义缓冲池很难比官方实现更高效：官方池已经做了多场景适配，会自动根据使用情况调整池的大小，峰值时自动扩容，低峰时自动释放闲置内存，不会一直占用系统资源。自己写固定大小的池要么会出现峰值不够用、低峰浪费内存的问题，要么需要额外开发复杂的调度逻辑，投入产出比极低。
• 除非你有非常特殊的定制需求，比如必须严格限制缓冲池的最大内存占用、需要对缓冲区做统一的预处理，否则完全没有必要自己造轮子。

内容的提问来源于stack exchange，提问作者user788454