原文链接：https://adamsitnik.com/Array-Pool/
使用ArrayPool
.NET的垃圾收集器（GC）实现了许多性能优化，其中之一就是，设定年轻的对象很快消亡，然而老的对象却可以生存很久。这就是为什么托管堆被划分为三个代。我们称呼他们为第0代（最年轻的）、第1代（短暂生存）、第2代（生存最长的）。新的对象默认都被分配到第0代。当GC尝试分配一个新的对象到第0代时并且发现第0代已经满了，就会触发第0代进行回收，这个被称呼为局部回收（仅仅回收第0代）。GC遍历整个对象图形，从最根部（局部变量，静态字段等）开始，将所有的引用对象标记为生存对象。
以上是第一阶段，被称为“标记”阶段，此阶段为非阻塞的。但是GC回收进程是阻塞的，GC会挂起所有的线程来执行下一步。
生存了的对象被提权（提权过程大部分时间都是消耗在数据拷贝上）到第1代，然后第0代被清空。第0代往往被设计为很小，所以执行第0代的回收会比较快。理想情况下，一个WEB请求，从开始请求到结束请求，所有被分配的对象都应该被回收掉。然后GC就可以将下一个对象指针移到第0代的起始位置。同理，根据第0代的回收逻辑，当第1代也满了之后，GC就不能再将第0代的对象进行提权到第1代了。接着GC就开始回收第1代的内存。第1代也很小，执行回收也很快，紧接着，第1代的生存者被提权到第2代。第2代里面都是生存期很长的对象，第2代非常大并且执行第2代的垃圾回收会非常非常耗时。所以针对于第2代的垃圾回收我们应该尽量避免，想知道为什么？让我们看看下面的视频然后看看第2代的垃圾回收是如何影响用户体验的。
大对象堆栈(LOH)每当GC将对象转移到新的一代时，都会进行内存拷贝。如你想象，如果是在拷贝一些大对象，例如大数组或者字符串时会尤其耗时。为了解决这种问题，GC有另一个优化手段，任何一个大于85000字节的对象都被认为是大对象，大对象存储在托管堆的单独部分中，称为大对象堆（LOH），该部分使用自由列表算法进行管理。这意味着GC有一个免费的内存段列表，当我们想要分配一些大的内容时，它会搜索列表以找到一个可行的内存段。因此，默认情况下，大对象永远不会在内存中移动。然而，如果遇到LOH碎片问题，则需要压缩LOH。从.NET 4.5.1开始，您可以按需执行此操作。
问题来了分配大对象时，它被标记为GC的第2代对象。不像小对象是默认放在第0代的。这种机制的结果就是如果你在LOH中耗尽内存，GC会清理整个托管堆（第0代、第1代、第2代以及LOH块），而不仅仅是LOH。这种行为被称为Full GC,是最为耗时的垃圾回收。对于许多应用，Full GC可以忍受，但是对于高性能的WEB服务器，实在是无法忍受，其中需要很少的大内存缓冲来处理平均的Web请求（例如从套接字读取，解压缩，解码JSON等等）。
要是想知道Full GC是不是你的应用性能问题，可以用内置的perfmon.exe程序获得简单的视图报告。
如你所见，对于我的Visual Studio程序来说，Full GC不是问题，我的Visual Studio应用程序已经运行了好几个小时了，第2代的回收相比于第0、1代来说要少很多。
解决方案解决方案非常简单：缓冲池。 池（Pool）是一组可以使用的初始化对象。我们不是分配新对象，而是从池中租用它。一旦我们完成使用，我们就将它返回到池中。每个大型托管对象都是一个数组或数组包装器（字符串包含一个长度字段和一个字符数组）。所以我们需要池数组来避免这个问题。
ArrayPool
代码示例 var samePool = ArrayPool<byte>.Shared; byte[] buffer = samePool.Rent(minLength); try { Use(buffer); } finally { samePool.Return(buffer); // don't use the reference to the buffer after returning it! } void Use(byte[] buffer) // it's an array 如何使用首先你需要一个初始化的池，至少有三种方式可以获得：
最建议的方式：使用 ArrayPool
使用 ArrayPool
从抽象ArrayPool
接下来，在获取了初始化池之后你就需要调用Rent方法，它需要你传入一个你想要的缓存的最小长度，请记住，Rent返回的内容可能比您要求的要大。
byte[] webRequest = request.Bytes; byte[] buffer = ArrayPool<byte>.Shared.Rent(webRequest.Length); Array.Copy( sourceArray: webRequest, destinationArray: buffer, length: webRequest.Length); // webRequest.Length != buffer.Length!!