.NET 8（Linux环境）下如何查看可用RAM与未回收垃圾以排查内存泄漏？

阿华AIGC实验室

2026-4-8

刚好在.NET 8 Linux环境下排查过类似的TcpClient内存泄漏问题，给你整理几个实用的方法，分系统级和.NET进程内两个维度来说，一步步定位问题：

一、查看系统级可用RAM与目标.NET进程内存占用

先从系统层面确认整体内存状态，以及你的.NET进程的内存消耗趋势：

用free -h快速查看系统整体可用内存，-h参数会以人性化的单位（GB/MB）显示，重点看available列——这是系统真正能分配给新进程的内存（包含可释放的缓存），比free列的参考价值更高。
定位到你的.NET进程内存占用，用top或htop：打开后按M键可按内存占用排序，找到你的dotnet进程，观察RES（常驻物理内存）和VIRT（虚拟内存）列，如果RES持续上涨且没有回落，大概率存在内存泄漏。
更精准的进程内存统计可以用ps aux | grep dotnet，其中RSS列就是进程实际占用的物理内存（单位KB），可以和top的结果交叉验证。

二、.NET进程内查看未回收垃圾与托管内存细节

这部分是排查托管内存泄漏的核心，尤其是像TcpClient这类实现了IDisposable的对象，没正确释放很容易导致资源挂起：

1. 用dotnet-counters实时监控（无需改代码）

这是.NET官方自带的轻量级诊断工具，.NET 8 SDK默认已包含，直接用即可：

先通过ps aux | grep dotnet拿到你的.NET进程ID（PID）。
运行dotnet-counters monitor --process-id <你的PID> System.Runtime，会实时输出关键指标：
- GC Heap Size：当前托管堆的总大小，如果该值持续上涨且在GC后没有明显回落，说明存在托管内存泄漏。
- Gen 0/1/2 Collections：各代垃圾回收的次数，如果Gen2（老年代）回收频繁，但堆大小依然居高不下，说明存在长期存活的对象没被回收（比如未Dispose的TcpClient持有底层资源）。
- Total Memory：进程的总内存占用（托管+非托管），能帮你区分是托管还是非托管内存泄漏。
要是想专门监控TcpClient相关的Socket资源，可运行dotnet-counters monitor --process-id <PID> System.Net.Sockets，重点看Socket Count指标——如果该数值持续增加，基本可以确定有TcpClient没被正确Dispose。

2. 用dotnet-dump抓取堆快照定位泄漏对象

当监控到异常后，就需要抓取堆快照来定位具体的泄漏对象：

先安装工具（如果未安装）：dotnet tool install --global dotnet-dump
抓取快照：dotnet-dump collect --process-id <PID>，执行后会在当前目录生成一个.dmp格式的堆快照文件。
分析快照：运行dotnet-dump analyze <快照文件名>进入交互模式，用以下命令排查：
- dumpheap -stat：查看托管堆中各类对象的数量和大小，搜索System.Net.Sockets.TcpClient或System.Net.Sockets.Socket，如果这些对象的数量远超业务预期，就是泄漏的核心对象。
- gcroot <对象地址>：针对可疑对象的内存地址，查找它的根引用（是什么在持有它不被GC回收），比如可能是事件未解绑、全局集合引用未清理等。

3. 用dotnet-gcdump分析GC回收详情

这个工具专门用于分析GC的行为，适合排查垃圾回收不及时或对象无法被回收的问题：

安装工具：dotnet tool install --global dotnet-gcdump
抓取GC快照：dotnet-gcdump collect --process-id <PID>，生成.gcdump格式的文件。
可以用VS Code的「.NET Memory Dump Analyzer」插件打开快照（Linux环境下完全支持），直观看到各代对象的分布、对象引用链，能快速找到哪些对象在持有未释放的TcpClient。

4. 代码埋点自定义监控（针对特定对象）

如果需要更精准地统计TcpClient的创建与释放情况，可以在代码中加个简单的计数器：

public static class TcpClientTracker
{
    private static int _createdCount;
    private static int _disposedCount;

    public static int CreatedCount => Interlocked.CompareExchange(ref _createdCount, 0, 0);
    public static int DisposedCount => Interlocked.CompareExchange(ref _disposedCount, 0, 0);

    public static void TrackCreated() => Interlocked.Increment(ref _createdCount);
    public static void TrackDisposed() => Interlocked.Increment(ref _disposedCount);
}

// 在创建TcpClient的地方调用
using var client = new TcpClient();
TcpClientTracker.TrackCreated();

// 在Dispose时调用（using声明会自动Dispose，可在TcpClient的包装类或Dispose方法里加）
try
{
    // 业务逻辑处理
}
finally
{
    client.Dispose();
    TcpClientTracker.TrackDisposed();
}

之后可以通过dotnet-counters暴露这个自定义计数器，或者在日志中定期输出TcpClientTracker.CreatedCount - TcpClientTracker.DisposedCount的差值——如果差值持续变大，说明有TcpClient未被正确释放。

三、针对TcpClient泄漏的额外注意点

务必用using声明（C# 8+支持using var）或在finally块中手动调用Dispose()：TcpClient实现了IDisposable，未正确释放会导致底层Socket资源（非托管内存）无法被回收，此时托管堆大小可能正常，但进程的物理内存（RES）会持续上涨。
排查异步场景：如果用了TcpClient的异步方法（如ConnectAsync），要确保异步操作完成后对象被正确释放，避免因异步回调持有对象引用导致无法回收。