記一次 .NET 某風控管理系統 記憶體洩漏分析

一線碼農發表於2021-11-02
記憶體

一：背景

1. 講故事

上個月中旬，星球裡的一位朋友在微信找我，說他的程式跑著跑著記憶體會不斷的緩慢增長並無法釋放，尋求如何解決 ？

得，看樣子星球還得好好弄！！！ ??? 不管怎麼說，先上 windbg 說話。

二：Windbg 分析

1. 經驗推理

從朋友的截圖看，有大量的 8216 位元組的 byte[]，這表示什麼呢？ 追隨本系列的朋友應該知道，有一篇 某三甲醫院 的記憶體暴漲的dump中，也同樣有此 size= (8216-24=8192) 的 byte[] 陣列， 他的問題是 Oracle 中讀取某大欄位時sdk裡的 OraBuf 出了問題，換句話說，這肯定又是底層或者第三方庫中的池物件搞出來的東西，接下來從 託管堆 看起。

2. 檢視託管堆


0:000> !dumpheap -stat
Statistics:
00007ffe107248f0   483707     15478624 System.Threading.PreAllocatedOverlapped
00007ffe1079c160   483744     15479808 System.Threading.ThreadPoolBoundHandle
00007ffe1079cff8   483701     23217648 System.Threading._IOCompletionCallback
00007ffe106e7a90   483704     23217792 Microsoft.Win32.SafeHandles.SafeFileHandle
00007ffe1079b088   483703     30956992 System.IO.FileSystemWatcher+AsyncReadState
00007ffe1079ceb0   483707     34826904 System.Threading.OverlappedData
00007ffe1079ccb0   483707     34826904 System.Threading.ThreadPoolBoundHandleOverlapped
0000016c64651080   245652   1473128080      Free
00007ffe105abf30   488172   3977571092 System.Byte[]

掃完託管堆，臥槽 ，byte[] 沒吸引到我，反而被 System.IO.FileSystemWatcher+AsyncReadState 吸引到了，畢竟被 System.IO.FileSystemWatcher 折騰多次了，它已經深深打入了我的腦海。。。畢竟讓程式卡死，讓控制程式碼爆高的都是它。。。這一回八成又是它惹的禍，看樣子還是有很多程式設計師栽在這裡哈。

為做到嚴謹，我還是從最大的 System.Byte[] 入手，按size對它進行分組再按totalsize降序，醜陋的指令碼我就不發了，直接上指令碼的輸出結果。


!dumpheap -mt 00007ffe105abf30
size=8216,count=483703,totalsize=3790M
size=8232,count=302,totalsize=2M
size=65560,count=6,totalsize=0M
size=131096,count=2,totalsize=0M
size=4120,count=11,totalsize=0M
size=56,count=301,totalsize=0M
size=88,count=186,totalsize=0M
size=848,count=16,totalsize=0M
size=152,count=85,totalsize=0M
size=46,count=242,totalsize=0M
size=279,count=38,totalsize=0M

!dumpheap -mt 00007ffe105abf30 -min 0n8216 -max 0n8216 -short

0000016c664277f0
0000016c66432a48
0000016c6648ef88
0000016c6649daa8
0000016c6649fb00
0000016c664a8b90
...

從輸出結果看，size=8216 的 byte[] 有 48w 個，然後指令碼也列出了一些 8216 大小的 address 地址，接下來用 !gcroot 看下這些地址的引用。


0:000> !gcroot 0000016c664277f0
HandleTable:
    0000016C65FC28C0 (async pinned handle)
    -> 0000016C6628DEB0 System.Threading.OverlappedData
    -> 0000016C664277F0 System.Byte[]

Found 1 unique roots (run '!gcroot -all' to see all roots).
0:000> !gcroot 0000016c667c80d0
HandleTable:
    0000016C65FB7920 (async pinned handle)
    -> 0000016C663260F8 System.Threading.OverlappedData
    -> 0000016C667C80D0 System.Byte[]

從輸出中可以看到這些 byte[] 都是 async pinned，也就是當非同步IO回來的時候需要給 byte[] 填充的儲存空間，接下來我們看看如何通過 OverlappedData 找到原始碼中定義為 8192 大小的 byte[] 地方。

如果你瞭解 FileSystemWatcher ，反向查詢鏈大概是這樣的 OverlappedData -> ThreadPoolBoundHandleOverlapped -> System.IO.FileSystemWatcher+AsyncReadState -> Buffer[]， 這中間涉及到 ThreadPool 和 SafeHandle 的繫結。


0:000> !do 0000016C663260F8
Name:        System.Threading.OverlappedData
MethodTable: 00007ffe1079ceb0
EEClass:     00007ffe107ac8d0
Size:        72(0x48) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.10\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffe106e3c08  40009ce        8  System.IAsyncResult  0 instance 0000000000000000 _asyncResult
00007ffe104a0c68  40009cf       10        System.Object  0 instance 0000016c66326140 _callback
00007ffe1079cb60  40009d0       18 ...eading.Overlapped  0 instance 0000016c663260b0 _overlapped
00007ffe104a0c68  40009d1       20        System.Object  0 instance 0000016c667c80d0 _userObject
00007ffe104af508  40009d2       28                  PTR  0 instance 00000171728f66e0 _pNativeOverlapped
00007ffe104aee60  40009d3       30        System.IntPtr  1 instance 0000000000000000 _eventHandle
00007ffe104ab258  40009d4       38         System.Int32  1 instance                0 _offsetLow
00007ffe104ab258  40009d5       3c         System.Int32  1 instance                0 _offsetHigh
0:000> !do 0000016c663260b0
Name:        System.Threading.ThreadPoolBoundHandleOverlapped
MethodTable: 00007ffe1079ccb0
EEClass:     00007ffe107ac858
Size:        72(0x48) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.10\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffe1079ceb0  40009d6        8 ...ng.OverlappedData  0 instance 0000016c663260f8 _overlappedData
00007ffe1079b818  40009c0       10 ...ompletionCallback  0 instance 0000016f661ab8a0 _userCallback
00007ffe104a0c68  40009c1       18        System.Object  0 instance 0000016c667ca0e8 _userState
00007ffe107248f0  40009c2       20 ...locatedOverlapped  0 instance 0000016c66326090 _preAllocated
00007ffe104af508  40009c3       30                  PTR  0 instance 00000171728f66e0 _nativeOverlapped
00007ffe1079c160  40009c4       28 ...adPoolBoundHandle  0 instance 0000000000000000 _boundHandle
00007ffe104a7238  40009c5       38       System.Boolean  1 instance                0 _completed
00007ffe1079b818  40009bf      738 ...ompletionCallback  0   static 0000016f661ab990 s_completionCallback
0:000> !do 0000016c667ca0e8
Name:        System.IO.FileSystemWatcher+AsyncReadState
MethodTable: 00007ffe1079b088
EEClass:     00007ffe107a9dc0
Size:        64(0x40) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.10\System.IO.FileSystem.Watcher.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffe104ab258  400002b       30         System.Int32  1 instance                1 <Session>k__BackingField
00007ffe105abf30  400002c        8        System.Byte[]  0 instance 0000016c667c80d0 <Buffer>k__BackingField
00007ffe106e7a90  400002d       10 ...es.SafeFileHandle  0 instance 0000016c66326028 <DirectoryHandle>k__BackingField
00007ffe1079c160  400002e       18 ...adPoolBoundHandle  0 instance 0000016c66326058 <ThreadPoolBinding>k__BackingField
00007ffe107248f0  400002f       20 ...locatedOverlapped  0 instance 0000016c66326090 <PreAllocatedOverlapped>k__BackingField
00007ffe1079b8c8  4000030       28 ...eSystem.Watcher]]  0 instance 0000016c66326078 <WeakWatcher>k__BackingField

上面的 <Buffer>k__BackingField 就是當初丟給 OverlappedData 作為 非同步IO 讀寫的緩衝，然後看下 System.IO.FileSystemWatcher+AsyncReadState 的原始碼。

有了這些原理之後，接下來就可以問朋友是否有對 appsettings 設定了 reloadonchange=true 的情況，朋友找了下程式碼，寫法大概如下：


public object GetxxxFlag()
{
    string value = AppConfig.GetConfig("appsettings.json").GetValue("xxxx", "0");

    return new
    {
        state = 200,
        data = value
    };
}

public class AppConfig
{
    public static AppConfig GetConfig(string settingfile = "appsettings.json")
    {
        return new AppConfig(settingfile);
    }
}

public class AppConfig
{
    private AppConfig(string settingfile)
    {
        _config = new ConfigurationBuilder().AddJsonFile(settingfile, optional: true, reloadOnChange: true).Build();
        _settingfile = settingfile;
    }
}

從原始碼邏輯看，我猜測朋友將 GetConfig 方法標記成 static 後就以為是單例化了，再次呼叫不會重複 new AppConfig(settingfile)，所以問題就出在這裡。

不過有意思的是，前面二篇的 FileSystemWatcher 都會造成程式卡死，那這一篇為啥沒有呢？恰好他沒有在程式根目錄中放日誌檔案，不然的話。。。???，可萬萬沒想到逃過了卡死卻沒逃過一個 watcher 預設 8byte 空間的靈魂拷問。。。???

三：總結

總的來說，設定 reloadOnChange: true 一定要慎重， 可能它會造成你的程式卡死，控制程式碼洩漏，記憶體洩漏 等等！！！ 改進方案我就不說了，參考我前面的系列文章吧。

圖片名稱

相關文章