共计 6293 个字符，预计需要花费 16 分钟才能阅读完成。
一：背景
1. 讲故事
上上周有位敌人找到我，说他的程序 CPU 和句柄都在一直的增长，无回头趋势，查了好些天也没什么停顿，特加 wx 寻求帮忙，截图如下：
看的进去这位敌人也是十分郁闷，出问题还出两个，气人哈，对于 cpu 爆高的问题我筹备独自用一篇文章去侦读，这篇就先聊聊 句柄透露 的问题，毕竟写了 20 多篇，也是第一次聊到 handle 泄露，有点意思哈。
2. 什么是句柄
我集体了解的句柄：就是在托管层持有了一个对非托管层资源的援用，有了这个援用，咱们就能够强制回收非托管资源，那什么是非托管资源？我集体的了解是 gc 管不到的中央都是 非托管资源。
通常蕴含这种句柄的类有：FileStream, Socket 等，如果大家有这个前置根底，接下来就能够用 windbg 去剖析啦！
二：windbg 剖析
1. 看问题表象
敌人从 工作管理器 中看到 handle =8770，那就阐明程序中有 8770 个对非托管资源持有句柄，那怎么去看呢? 在说这个之前，大家有没有遇到这种景象，就是不论程序怎么透露，只有咱们退出 exe，那么所有的资源都会被神奇的 开释, 不论是托管资源还是非托管资源，这样说置信有很有敌人好奇这是怎么实现的？？？大家能够先想 10s。
揭晓答案啦！简略的说, CLR 在外部保护了一张句柄表，当程序敞开时，CLR 会强制开释句柄表中的所有句柄，那问题就简略了，既然 CLR 能触达，我置信通过 windbg 也能做到，对，就是通过 !gchandles 命令。
2. 查看句柄表
这里揭示一下，!gchandles 的作用域是 AppDomain，而不是 Process，接下来看一下命令输入：
0:000> !gchandles -stat
Statistics:
MT Count TotalSize Class Name
...
00007ffccc1d2360 3 262280 System.Byte[]
00007ffccc116610 72 313224 System.Object[]
00007ffccc3814a0 8246 593712 System.Threading.OverlappedData
Total 10738 objects
Handles:
Strong Handles: 312
Pinned Handles: 18
Async Pinned Handles: 8246
Ref Count Handles: 1
Weak Long Handles: 2080
Weak Short Handles: 59
Dependent Handles: 22
从输入看，有一组数据特地扎眼，那就是：Async Pinned Handles = 8246 [System.Threading.OverlappedData]，这是什么意思呢？从英文名就能看出这是一个和 异步 IO 相干的句柄，有些敌人应该晓得，在异步 IO 的过程中，会有一个 byte[] 被 pinned 住，同时还有一个异步 IO 的上下文对象 OverlappedData。
接下来的一个问题是：既然是异步 IO，那它的 handle 是什么类型，如后面所说是 FileStream 还是 Socket？要想找出答案，就须要深挖 OverlappedData 对象, 相干的命令是：!dumpheap -mt xxx & !do ...，参考如下：
0:000> !DumpHeap /d -mt 00007ffccc3814a0
Address MT Size
000001aa2acb39c8 00007ffccc3814a0 72
000001aa2acb3fd8 00007ffccc3814a0 72
000001aa2ad323d0 00007ffccc3814a0 72
...
0:000> !do 000001aa2acb39c8
Name: System.Threading.OverlappedData
MethodTable: 00007ffccc3814a0
EEClass: 00007ffccc37ca18
Size: 72(0x48) bytes
File: C:\xxx\xxx\vms_210819\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffccc21f508 40006b2 8 System.IAsyncResult 0 instance 0000000000000000 _asyncResult
00007ffccc110ae8 40006b3 10 System.Object 0 instance 000001aa2acb4020 _callback
00007ffccc381150 40006b4 18 ...eading.Overlapped 0 instance 000001aa2acb3980 _overlapped
00007ffccc110ae8 40006b5 20 System.Object 0 instance 000001aa2acb9fe8 _userObject
00007ffccc11f130 40006b6 28 PTR 0 instance 000001aa2a9bd830 _pNativeOverlapped
00007ffccc11ecc0 40006b7 30 System.IntPtr 1 instance 0000000000000000 _eventHandle
0:000> !DumpObj /d 000001aa2acb3980
Name: System.Threading.ThreadPoolBoundHandleOverlapped
MethodTable: 00007ffccc3812a0
EEClass: 00007ffccc37c9a0
Size: 72(0x48) bytes
File: C:\xxx\xxx\vms_210819\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffccc3814a0 40006ba 8 ...ng.OverlappedData 0 instance 000001aa2acb39c8 _overlappedData
00007ffccc34fcd0 40006a4 10 ...ompletionCallback 0 instance 000001aa2acb3920 _userCallback
00007ffccc110ae8 40006a5 18 System.Object 0 instance 000001aa2acb38c8 _userState
00007ffccc380120 40006a6 20 ...locatedOverlapped 0 instance 000001aa2acb3960 _preAllocated
00007ffccc11f130 40006a7 30 PTR 0 instance 000001aa2a9bd830 _nativeOverlapped
00007ffccc380eb8 40006a8 28 ...adPoolBoundHandle 0 instance 000001aa2acb3900 _boundHandle
00007ffccc1171c8 40006a9 38 System.Boolean 1 instance 0 _completed
00007ffccc34fcd0 40006a3 458 ...ompletionCallback 0 static 000001aa2acb4020 s_completionCallback
0:000> !DumpObj /d 000001aa2acb3900
Name: System.Threading.ThreadPoolBoundHandle
MethodTable: 00007ffccc380eb8
EEClass: 00007ffccc37c870
Size: 32(0x20) bytes
File: C:\xxx\xxx\vms_210819\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffccc1d76b0 40006a1 8 ...rvices.SafeHandle 0 instance 000001aa2acb1d30 _handle
00007ffccc1171c8 40006a2 10 System.Boolean 1 instance 0 _isDisposed
0:000> !DumpObj /d 000001aa2acb1d30
Name: Microsoft.Win32.SafeHandles.SafeFileHandle
MethodTable: 00007ffccc3807c8
EEClass: 00007ffccc37c548
Size: 48(0x30) bytes
File: C:\xxx\xxx\xxx\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffccc11ecc0 4000bb4 8 System.IntPtr 1 instance 0000000000000428 handle
00007ffccc11b1e8 4000bb5 10 System.Int32 1 instance 4 _state
00007ffccc1171c8 4000bb6 14 System.Boolean 1 instance 1 _ownsHandle
00007ffccc1171c8 4000bb7 15 System.Boolean 1 instance 1 _fullyInitialized
00007ffccc2f1ae0 4001c3d 20 ...Private.CoreLib]] 1 instance 000001aa2acb1d50 _isAsync
00007ffccc380eb8 4001c3e 18 ...adPoolBoundHandle 0 instance 0000000000000000 <ThreadPoolBinding>k__BackingField
下面倒数第五行的 0000000000000428 就是具体的 handle 值，接下来就能够用 !handle 命令查看其值的具体信息。
0:000> !handle 0000000000000428 7
Handle 428
Type File
Attributes 0
GrantedAccess 0x100081:
Synch
Read/List,ReadAttr
HandleCount 2
PointerCount 65489
从 Type：File 能够看出，原来这 8000 多都是文件句柄哈。。。
写到这里貌似就到了死胡同了😪😪😪，尽管挖了一些信息，但这些信息还不足以让我找到问题本源，从援用链上来说，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 进行数据感知，问题就呈现在这里。。。
三：总结
其实本次事变的次要起因还是在于对如何实时感知 appsettings 中最新数据的玩法不相熟，一边用了 .netcore 自带的 reloadOnChange 监控，一边还用轮询的形式进行数据感知，所以说根底还是很重要的，不要想当然的去写！😁😁😁
更多高质量干货：参见我的 GitHub: dotnetfly