一次对pool的误用导致的.net频繁gc的诊断分析
(最近有读者朋友表示，希望能加一些示意图来描述分析过程中用到的原理知识。好的，之后我会注意，谢谢这位读者)
背景
有位朋友找我，希望我能帮看一下他的一个service。从他的描述看，并没有资源方面的泄漏，程序目前也能正常工作。他是在用dotnet-counters moniter时发现gc2、也就是full gc触发的比较频繁，频率超过了他自己的预期，于是他心里不踏实，所以想找我看一下。
能在没发生资源或性能异常前自觉monitor .net metrics的人，我跟佩服，这是讲究人儿啊。那后面我就管这位朋友叫"精致大哥"了哈
分析
其实对于这次没有明确内存泄漏迹象的问题，我没啥把握能给出明确问题点，甚至可能就是没问题。但，试试吧，拿出windbg准备。
既然是频繁full gc, 而且还都把内存降下来了，那么最先想到的是会不会在申请大量的大对象。
因为如果有很多小对象在申请内存，一般都会在gc0和gc1阶段搞定，而无需总劳烦gc2；或者申请很多小对象，而且还一直引用着，这样也能造成gc2，但那样的话内存应该也会泄漏才对。
带着这个猜想，先看一下大对象堆LOH的大小:
可以看到很多gc heap的LOH都被申请了4194384 byte大小。
然后去看看heap4里的LOH存的都是些什么。根据heap4的LOH segment的起始位置和allocation end 位置，用!dumpheap:
可以看出这里面只有一个byte array, 而且大小也是约4M。
尝试用!gcroot看一下这个大对象的引用关系:
这回gcroot无法给出想要的答案。这是因为引用它的引用链的head没有了引用根，画个示意图:
(这样一来，下次同代gc触发时，这个大对象的内存也就真的被释放了)
引用链找不到，线索断了。别急，既然sos不能帮助我们了，可以试试耐下心手动找引用链。我们知道一个对象的地址的值通常会存在某个对象所占用内存的"身上"，如图所示:
那么就可以先从当前gc heap的起始位置找一下这个大对象的地址值所在的内存位置。考虑到当前进程是小端模式，所以用如下命令:
1 0:000> s -b 0000021000000000 L?2000000000 38 10 95 32 1e 02 2 00000218`f29c9b38 38 10 95 32 1e 02 00 00-00 00 00 00 00 00 00 00
在内存位置218`f29c9b38找到了对象的地址值，接着找一下“包含”这个位置的对象：
1 Before: 00000218f29c9b28 4024 (0xfb8) System.Byte[][] 2 After: 00000218f29caae0 72 (0x48) System.Threading.Tasks.Task+DelayPromise
看来我们已经到了一个System.Byte[][]对象的位置了。按上面的思路继续搜寻218f29c9b28这个值：
1 0:000> s -b 0000021000000000 L?2000000000 28 9b 9c f2 18 02 2 00000218`f29c9ae8 28 9b 9c f2 18 02 00 00-00 00 40 00 db 52 a1 03 (.........@..R..
再找“包含”这个位置的对象：
1 Before: 00000218f29c9ae0 48 (0x30) System.Buffers.ConfigurableArrayPool`1+Bucket[[System.Byte, System.Private.CoreLib]] 2 After: 00000218f29c9b10 24 (0x18) Free
以此类推，又经过一系列搜寻，最后找到了这个对象，它的地址值在这个进程空间中无法被找到了:
Before: 00000218f29b7af0 24 (0x18) System.Buffers.ConfigurableArrayPool`1[[System.Byte, System.Private.CoreLib]]
于是认为已经找到了整个引用链的"临时"head。说它是"临时"的，是因为没有gc root引用着它。
有了这些数据，我们便可以用常规的sos指令进行一下正向的验证，从head 218f29b7af0 开始往下验证吧：
可以看到它确实引用着218f29b7b08 _buckets，
可以看到_buckets这个Bucket<byte>[]有19个元素，第18个元素确实就是上面推导的Bucket instance，继续看：
可以看到这个bucket instance（00000218f29c9ae0）确实hold着218f29c9b28 这个byte[][]，而这个byte[][]里也确实包含了我们最初要找的那个大对象byte[]：
好了，现在可以画个逆向诊断的引用复原图:
如果大家看过ArrayPool的一些基本实现，就知道这个ConfigurableArrayPool`1其实是ArrayPool.Create(config)创建出来的，所以我们调研的那个大对象byte[]其实是ArrayPool里维护的buffer。
又看了一下，进程中当时有18个这样大小的大byte[]：
按上面类似的推导，随机看了其他几个byte[]，其引用链的head都是不同的ConfigurableArrayPool`1 instances，所以对了一下ConfigurableArrayPool`1的数量，用!dumpheap:
也是18个。所以说，貌似每个Pool只管理了1个byte[] ?? 这样就有问题了，因为这样的话相当于每个pool都不能reuse 已有的其他pool的buffers，pool没有起到pool的作用。所以每次需要用buffer时，只能不断申请新的大byte[]，导致大对象数量增长。
后记
把这个分析结果告诉了那位“精致大哥”后，“精致大哥”找到了创建pool的代码，简化后是这样的：
1 private DigestSummary CalculateDigestSummary(NotificationEvent notificationEvent) 2 { 3 var bytesPool = ArrayPool<byte>.Create(4 * 1024 * 1024, 500); 4 byte[] buf = bytesPool.Rent(4 * 1024 * 1024); 5 ? 6 try 7 { 8 return CalculateWithBuffer(buf); 9 } 10 finally 11 { 12 bytesPool.Return(buf); 13 } 14 }
看第3行，每次需要byte[]时，都先创建一个pool，下次又重新用新pool。于是效果就是没有pool啦。
总结
应该在使用buffer的scope中尽量reuse pool instance, 或者也可以用
var bytesPool = ArrayPool<byte>.Shared;
这次gc问题的诊断分析，需要脱离sos，手动找引用关系，从而获得了“这次大对象是ArrayPool挂着”这层信息，进而找出了ArrayPool instances与大byte[] instances一对一的不正常关系。