写到这里貌似就到了死胡同了😪😪😪，虽然挖了一些信息，但这些信息还不足以让我找到问题根源，从引用链上来说，gchandles 中的这些对象是处于引用链的顶端，换句话说，我需要找到这条引用链下游的一些数据对象，一个好的入口点就是到 heap 中去挖。
3. 从托管堆找 OverlappedData 的徒孙辈首先我们用 !dumpheap -stat 查看下托管堆。
0:000> !dumpheap -stat Statistics: MT Count TotalSize Class Name ... 00007ffccc3c5e18 939360 52604160 System.Collections.Generic.SortedSet`1+Node[[System.Collections.Generic.KeyValuePair`2[[System.String, System.Private.CoreLib],[System.String, System.Private.CoreLib]], System.Private.CoreLib]] 00007ffccc1d2360 16492 69081162 System.Byte[] 000001aa2a99af00 10365 76689384 Free 00007ffccc1d1e18 1904987 116290870 System.String
既然是找引用链下游，那就从基础类型 System.String 或者 System.Byte[] 入手，这里我就选择前者，写了一个对 mt 下所有 address 进行分组统计的脚本，毕竟人肉是不可能的，从脚本的输出中我抽了几个 address 查看 !gcroot，大概都是类似这样的内容。
0:000> !gcroot 000001aa47a0c030 HandleTable: 000001AA4469C090 (async pinned handle) -> 000001AA491EB908 System.Threading.OverlappedData -> 000001AA491EB8C0 System.Threading.ThreadPoolBoundHandleOverlapped -> 000001AA491EB860 System.Threading.IOCompletionCallback -> 000001AA491EAF30 System.IO.FileSystemWatcher -> 000001AA491EB458 System.IO.FileSystemEventHandler ... -> 000001AA47A0C030 System.String 0:000> !gcroot 000001aa2d3ea480 HandleTable: 000001AA28FE9930 (async pinned handle) -> 000001AA2DD68220 System.Threading.OverlappedData -> 000001AA2DD681D8 System.Threading.ThreadPoolBoundHandleOverlapped -> 000001AA2DD68178 System.Threading.IOCompletionCallback -> 000001AA2DD67848 System.IO.FileSystemWatcher ... -> 000001AA2D3EA480 System.String
从整个引用链来看，里面都有一个 System.IO.FileSystemWatcher ，这和前面分析的 handle= File 是一致的，然后就是导出这些 string ，发现大部分都是和 appSettings 相关，如下所示：
string: appSettings:RabbitMQLogQueue string: appSettings:MedicalMediaServerIP string: appSettings:UseHttps ...
然后用 !strings 命令进行了模糊匹配，发现这样的string 高达 61w 。。。
到这里基本就能断定：appsettings 被 watch 了，但 watch 的方式有问题。。。
4. 寻找最终答案将调查结果给了朋友之后，让朋友着重观察下对 appsetting 进行 watch 的方式是否有问题？ 几个小时后，朋友终于找到了。
大概意思是说：本身已经通过设置 reloadOnChange=true 对 appsetings 进行了监控，但写码的人对这一块不熟悉，又通过每10s一次轮询对appsettings进行数据感知，问题就出现在这里。。。
三：总结