.NET關(guān)于API 句柄泄漏分析

更新時(shí)間：2021年08月31日 08:56:22 作者：一線碼農(nóng)

本文主要介紹了.NET關(guān)于API 句柄泄漏分析，文中結(jié)合代碼與圖片講解的非常詳細(xì)，感興趣的小伙伴可以自行參考一下

一：背景

1. 講故事

上上周有位朋友找到我，說他的程序CPU和句柄都在不斷的增長，無回頭趨勢，查了好些天也沒什么進(jìn)展，特加wx尋求幫助，截圖如下：

看的出來這位朋友也是非常郁悶，出問題還出兩個(gè)，氣人哈，關(guān)于 cpu 爆高的問題我準(zhǔn)備單獨(dú)用一篇文章去偵讀，這篇就先聊聊 句柄泄漏 的問題，畢竟寫了20多篇，也是第一次聊到 handle 泄露，有點(diǎn)意思哈。

2. 什么是句柄

我個(gè)人理解的句柄：就是在托管層持有了一個(gè)對(duì)非托管層資源的引用，有了這個(gè)引用，我們就可以強(qiáng)制回收非托管資源，那什么是非托管資源？我個(gè)人的理解是 gc 管不到的地方都是 非托管資源。

通常包含這種句柄的類有： FileStream, Socket 等，如果大家有這個(gè)前置基礎(chǔ)，接下來就可以用 windbg 去分析啦！

二： windbg 分析

1. 看問題表象

朋友從 任務(wù)管理器 中看到 handle =8770，那就說明程序中有 8770 個(gè)對(duì)非托管資源持有句柄，那怎么去看呢? 在說這個(gè)之前，大家有沒有遇到這種現(xiàn)象，就是不管程序怎么泄漏，只要我們退出exe，那么所有的資源都會(huì)被神奇的釋放, 不管是托管資源還是非托管資源，這樣說相信有很有朋友好奇這是怎么實(shí)現(xiàn)的？？？大家可以先想 10s。

揭曉答案啦！簡單的說, CLR 在內(nèi)部維護(hù)了一張句柄表，當(dāng)程序關(guān)閉時(shí)，CLR會(huì)強(qiáng)制釋放句柄表中的所有句柄，那問題就簡單了，既然 CLR 能觸達(dá)，我相信通過 windbg 也能做到，對(duì)，就是通過 !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

從輸出看，有一組數(shù)據(jù)特別刺眼，那就是： Async Pinned Handles = 8246 [System.Threading.OverlappedData]，這是什么意思呢？從英文名就能看出這是一個(gè)和 異步IO 相關(guān)的句柄，有些朋友應(yīng)該知道，在異步IO的過程中，會(huì)有一個(gè) byte[] 被 pinned 住，同時(shí)還有一個(gè)異步IO的上下文對(duì)象 OverlappedData。

接下來的一個(gè)問題是：既然是異步IO，那它的 handle 是什么類型，如前面所說是 FileStream 還是 Socket ？要想找出答案，就需要深挖 OverlappedData 對(duì)象,相關(guān)的命令是： !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

上面倒數(shù)第五行的 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 中的這些對(duì)象是處于引用鏈的頂端，換句話說，我需要找到這條引用鏈下游的一些數(shù)據(jù)對(duì)象，一個(gè)好的入口點(diǎn)就是到 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

既然是找引用鏈下游，那就從基礎(chǔ)類型 System.String 或者 System.Byte[] 入手，這里我就選擇前者，寫了一個(gè)對(duì) mt 下所有 address 進(jìn)行分組統(tǒng)計(jì)的腳本，畢竟人肉是不可能的，從腳本的輸出中我抽了幾個(gè) address 查看 !gcroot，大概都是類似這樣的內(nèi)容。

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

從整個(gè)引用鏈來看，里面都有一個(gè) System.IO.FileSystemWatcher ，這和前面分析的 handle= File 是一致的，然后就是導(dǎo)出這些 string ，發(fā)現(xiàn)大部分都是和 appSettings 相關(guān)，如下所示：

string: appSettings:RabbitMQLogQueue
string: appSettings:MedicalMediaServerIP
string: appSettings:UseHttps
...

然后用 !strings 命令進(jìn)行了模糊匹配，發(fā)現(xiàn)這樣的string 高達(dá) 61w 。。。

到這里基本就能斷定：appsettings 被 watch 了，但 watch 的方式有問題。。。

4. 尋找最終答案

將調(diào)查結(jié)果給了朋友之后，讓朋友著重觀察下對(duì) appsetting 進(jìn)行 watch 的方式是否有問題？幾個(gè)小時(shí)后，朋友終于找到了。

大概意思是說：本身已經(jīng)通過設(shè)置 reloadOnChange=true 對(duì) appsetings 進(jìn)行了監(jiān)控，但寫碼的人對(duì)這一塊不熟悉，又通過每10s一次輪詢對(duì)appsettings進(jìn)行數(shù)據(jù)感知，問題就出現(xiàn)在這里。。。

三：總結(jié)

其實(shí)本次事故的主要原因還是在于對(duì)如何實(shí)時(shí)感知 appsettings 中最新數(shù)據(jù)的玩法不熟悉，一邊用了 .netcore 自帶的 reloadOnChange 監(jiān)控，一邊還用輪詢的方式進(jìn)行數(shù)據(jù)感知，所以說基礎(chǔ)還是很重要的，不要想當(dāng)然的去寫！ 😁😁😁

到此這篇關(guān)于.NET關(guān)于API 句柄泄漏分析的文章就介紹到這了,更多相關(guān).NET API 句柄泄漏內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: