本文适用于：
✔️ .NET Core 3.1 SDK 及更高版本
当应用引用不再需要执行所需任务的对象时，内存可能会泄漏。 引用这些对象可防止垃圾回收器回收使用的内存。 这可能会导致性能下降并引发
OutOfMemoryException
异常。
本教程演示了使用 .NET 诊断 CLI 工具分析 .NET 应用中的内存泄漏的工具。 如果使用的是 Windows，则可能可以使用
Visual Studio 的内存诊断工具来
调试内存泄漏。
本教程使用故意泄漏内存的示例应用作为练习。 还可以分析无意中泄漏内存的应用。
在本教程中，你将：
使用
dotnet-counters
检查托管内存使用情况。
生成转储文件。
使用转储文件分析内存使用情况。
本教程使用：
.NET Core 3.1 SDK
或更高版本。
使用
dotnet-counters
检查托管内存的使用情况。
用于收集和分析转储文件的
dotnet-dump
（包括
SOS 调试扩展
）。
用于诊断的
示例调试目标
应用。
本教程假定示例应用和工具已安装并可供使用。
检查托管内存使用情况
在收集诊断数据以帮助分析此问题之前，请确保已经确认真的存在内存泄漏（内存使用增加）。 可以使用
dotnet-counters
工具确认这一点。
打开控制台窗口并导航到下载并解压缩
示例调试目标的
目录。 运行目标：
dotnet run
在单独的控制台中，找到进程 ID：
dotnet-counters ps
输出应如下所示：
4807 DiagnosticScena /home/user/git/samples/core/diagnostics/DiagnosticScenarios/bin/Debug/netcoreapp3.0/DiagnosticScenarios
如果上一个命令不起作用或未找到，则可能需要先安装该工具 dotnet-counters 。 使用以下命令：
dotnet tool install --global dotnet-counters
现在，使用 dotnet-counters 工具检查托管内存使用情况。 --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
集中注意力于这一行：
GC Heap Size (MB) 4
可以在启动后看到托管堆内存为 4 MB。
现在，转到 URL https://localhost:5001/api/diagscenario/memleak/20000。
请注意，内存使用量已增加到 30 MB。
GC Heap Size (MB) 30
通过观察内存使用情况，可以安全地说内存正在增长或泄漏。 下一步是收集正确的数据进行内存分析。
生成内存转储
分析可能的内存泄漏时，需要访问应用的内存堆来分析内存内容。 查看对象之间的关系，可以创建关于内存未释放的原因的理论。 常见的诊断数据源是 Windows 上的内存转储或 Linux 上的等效核心转储。 若要生成.NET 应用程序的转储，可以使用dotnet-dump工具。
使用以前启动的示例调试目标，运行以下命令以生成Linux核心转储：
dotnet-dump collect -p 4807
结果是位于同一文件夹中的核心转储。
Writing minidump with heap to ./core_20190430_185145
Complete
为了随时间推移进行比较，让原始进程在收集第一个转储后继续运行，并采用相同的方式收集第二个转储。 然后，你将在一段时间内有两个转储，你可以比较这些转储，以查看内存使用量的增长位置。
重启失败的进程
收集转储后，你应该有足够的信息来诊断失败的进程。 如果失败的进程在生产服务器上运行，则现在是通过重启进程来短期修正的理想时间。
在本教程中，现在已完成 示例调试目标 ，可以将其关闭。 导航到启动服务器的终端，然后按 Ctrl+C。
分析核心转储
生成核心转储后，请使用 dotnet-dump 工具分析核心转储。
dotnet-dump analyze core_20190430_185145
其中 core_20190430_185145 是要分析的核心转储的名称。
如果看到一个错误，提示找不到 libdl.so，则可能必须安装 libc6-dev 包。 有关详细信息，请参阅 Linux 上 .NET 的先决条件。
你将看到一个提示，你可以在其中输入 SOS 命令。 通常，首先要查看的是托管堆的整体状态：
> 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 对象。
可以再次将 dumpheap 命令与方法表（MT）一起使用，以获取所有 String 实例的列表：
> dumpheap -mt 00007f6c1dc00f90
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
现在可以在 System.String 实例上使用 gcroot 命令来查看对象的根化方式和原因。
> gcroot 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 对象直接持有 Customer ，并间接由对象 CustomerCache 持有。
可以继续转储对象，以查看大多数 String 对象是否遵循类似的模式。 此时，调查提供了足够的信息来识别代码中的根本原因。
此常规过程允许识别主要内存泄漏的来源。
在本教程中，你已启动一个示例 Web 服务器。 此服务器应已关闭，如 “重启失败的进程 ”部分中所述。
还可以删除已创建的转储文件。
dotnet-trace 列出进程
dotnet-counters 检查托管内存的使用情况。
dotnet-dump 用于收集和分析转储文件
dotnet/diagnostics
使用 Visual Studio 调试内存泄漏
在 .NET Core 中调试高 CPU 使用率
