快捷導(dǎo)航

一篇文章教你如何排查.NET內(nèi)存泄漏

更新時(shí)間：2021年09月27日 11:15:08 作者：Microsoft

這篇文章主要給大家介紹了如何通過一篇文章教你排查 .NET 內(nèi)存泄漏的相關(guān)資料,.NET內(nèi)存泄漏，更準(zhǔn)確的說應(yīng)該是對象超過生命周期而不能被GC回收,本文通過示例代碼介紹的非常詳細(xì),需要的朋友可以參考下

前言

內(nèi)存泄漏通常表示：一個(gè)應(yīng)用程序的某些對象在完成它的的生命周期后，由于它被其他對象意外引用，導(dǎo)致后續(xù)gc無法對它進(jìn)行回收，長此以往就會(huì)導(dǎo)致程序性能的下降以及潛在的 OutOfMemoryException。

這篇我們通過一個(gè)內(nèi)存泄漏工具對 .NET Core 程序進(jìn)行內(nèi)存泄漏分析，如果程序是跑在windows上，那直接可以使用 Visual Studio 進(jìn)行診斷。

檢查托管內(nèi)存使用

在開始分析內(nèi)存泄漏之前，你一定要有證據(jù)證明真的存在內(nèi)存泄漏，這里可以用 dotnet-counters 來看下應(yīng)用程序的各個(gè)指標(biāo)來進(jìn)行驗(yàn)證。

將程序跑起來

dotnet run

找出程序的 pid，

dotnet-counters ps

4807 DiagnosticScena /home/user/git/samples/core/diagnostics/DiagnosticScenarios/bin/Debug/netcoreapp3.0/DiagnosticScenarios

使用 monitor 啟動(dòng)監(jiān)視器，這里的 --refresh-interval 表示刷新間隔

dotnet-counters monitor --refresh-interval 1 -p 4807
Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    # of Assemblies Loaded                           118
    % Time in GC (since last GC)                       0
    Allocation Rate (Bytes / sec)                 37,896
    CPU Usage (%)                                      0
    Exceptions / sec                                   0
    GC Heap Size (MB)                                  4
    Gen 0 GC / sec                                     0
    Gen 0 Size (B)                                     0
    Gen 1 GC / sec                                     0
    Gen 1 Size (B)                                     0
    Gen 2 GC / sec                                     0
    Gen 2 Size (B)                                     0
    LOH Size (B)                                       0
    Monitor Lock Contention Count / sec                0
    Number of Active Timers                            1
    ThreadPool Completed Work Items / sec             10
    ThreadPool Queue Length                            0
    ThreadPool Threads Count                           1
    Working Set (MB)                                  83

重點(diǎn)看一下 GC Heap Size (MB) 指標(biāo)，可以看到程序啟動(dòng)后當(dāng)前GC堆內(nèi)存為 4M，打開鏈接：https://localhost:5001/api/diagscenario/memleak/20000 后再看看GC堆內(nèi)存,可以看到一下子就到 30M 了，如下所示：

GC Heap Size (MB) 30

通過對比內(nèi)存的使用，這下子可以拍胸脯的說，確認(rèn)內(nèi)存內(nèi)存泄漏。

生成dump文件

要想分析程序的內(nèi)存泄漏，首先要有訪問GC堆的權(quán)限，這樣就可以分析heap內(nèi)存以及對象之間的關(guān)系，然后就可以大膽猜想為啥內(nèi)存沒有得到釋放？要想生成 .NET Core 程序的dump文件，可以借助 dotnet-dump 工具。

dotnet-dump collect -p 4807
Writing minidump with heap to ./core_20190430_185145
Complete

分析 core dump

接下來可以使用 dotnet-dump analyze 對已生成的dump文件進(jìn)行分析。

dotnet-dump analyze core_20190430_185145

這里的 core_20190430_185145 就是你想要分析的dump名，值得一提的是：如果你遇到了 libdl.so cannot be found 錯(cuò)誤，建議以安裝一下 libc6-dev package 包。

首先我們通過 sos 命令查看托管堆上的所有對象統(tǒng)計(jì)清單。

> dumpheap -stat

Statistics:
              MT    Count    TotalSize Class Name
...
00007f6c1eeefba8      576        59904 System.Reflection.RuntimeMethodInfo
00007f6c1dc021c8     1749        95696 System.SByte[]
00000000008c9db0     3847       116080      Free
00007f6c1e784a18      175       128640 System.Char[]
00007f6c1dbf5510      217       133504 System.Object[]
00007f6c1dc014c0      467       416464 System.Byte[]
00007f6c21625038        6      4063376 testwebapi.Controllers.Customer[]
00007f6c20a67498   200000      4800000 testwebapi.Controllers.Customer
00007f6c1dc00f90   206770     19494060 System.String
Total 428516 objects

從輸出看，大頭都是些 String 和 Customer 對象,然后可以通過 mt 參數(shù)來獲取該方法表下所有的實(shí)例對象。

> dumpheap -mt 00007faddaa50f90

         Address               MT     Size
...
00007f6ad09421f8 00007faddaa50f90       94
...
00007f6ad0965b20 00007f6c1dc00f90       80
00007f6ad0965c10 00007f6c1dc00f90       80
00007f6ad0965d00 00007f6c1dc00f90       80
00007f6ad0965df0 00007f6c1dc00f90       80
00007f6ad0965ee0 00007f6c1dc00f90       80

Statistics:
              MT    Count    TotalSize Class Name
00007f6c1dc00f90   206770     19494060 System.String
Total 206770 objects

接下來可以用 !gcroot 查看某一個(gè)string到底被誰持有著？

> gcroot -all 00007f6ad09421f8

Thread 3f68:
    00007F6795BB58A0 00007F6C1D7D0745 System.Diagnostics.Tracing.CounterGroup.PollForValues() [/_/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/CounterGroup.cs @ 260]
        rbx:  (interior)
            ->  00007F6BDFFFF038 System.Object[]
            ->  00007F69D0033570 testwebapi.Controllers.Processor
            ->  00007F69D0033588 testwebapi.Controllers.CustomerCache
            ->  00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer, DiagnosticScenarios]]
            ->  00007F6C000148A0 testwebapi.Controllers.Customer[]
            ->  00007F6AD0942258 testwebapi.Controllers.Customer
            ->  00007F6AD09421F8 System.String

HandleTable:
    00007F6C98BB15F8 (pinned handle)
    -> 00007F6BDFFFF038 System.Object[]
    -> 00007F69D0033570 testwebapi.Controllers.Processor
    -> 00007F69D0033588 testwebapi.Controllers.CustomerCache
    -> 00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer, DiagnosticScenarios]]
    -> 00007F6C000148A0 testwebapi.Controllers.Customer[]
    -> 00007F6AD0942258 testwebapi.Controllers.Customer
    -> 00007F6AD09421F8 System.String

Found 2 roots.

從string的引用鏈看，它是被 CustomerCache 所持有，然后就可以到代碼中尋找問題啦。

原文鏈接：https://docs.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak