.NET Core对象池应用在哪些长尾场景下可以发挥其扩展优势？

本文共计2759个文字，预计阅读时间需要12分钟。

目录：

一、池化集合

二、池化StringBuilder

三、ArrayPool

四、MemoryPool

原则：在原规则上，所有可引用类型对象都可以通过对象池来提供，但在具体应用中，是否使用对象池需要权衡权限。当然，对象池可以通过以下方式提供：

目录

• 一、池化集合
• 二、池化StringBuilder
• 三、ArrayPool<T>
• 四、MemoryPool<T>

原则上所有的引用类型对象都可以通过对象池来提供，但是在具体的应用中需要权衡是否值得用。虽然对象池能够通过对象复用的方式避免GC，但是它存储的对象会耗用内存，如果对象复用的频率很小，使用对象池是不值的。如果某个小对象的使用周期很短，能够确保GC在第0代就能将其回收，这样的对象其实也不太适合放在对象池中，因为第0代GC的性能其实是很高的。除此之外，对象释放到对象池之后就有可能被其他线程提取出来，如果释放的时机不对，有可能造成多个线程同时操作同一个对象。总之，我们在使用之前得考虑当前场景是否适用对象池，在使用的时候严格按照“有借有还”、“不用才还”的原则。

一、池化集合

我们知道一个List<T>对象内部会使用一个数组来保存列表元素。数组是定长的，所以List<T>有一个最大容量（体现为它的Capacity属性）。当列表元素数量超过数组容量时，必须对列表对象进行扩容，即创建一个新的数组并将现有的元素拷贝进去。当前元素越多，需要执行的拷贝操作就越多，对性能的影响自然就越大。