探秘ASP.NET Core中的内存管理和模式

2024-05-21 07:29:14作者：昌雅子Ethen

memoryleak

暂无简介

在.NET这样的托管框架中，内存管理复杂而微妙，对内存问题的分析和理解常常令人头痛。最近一个用户在ASP.NET Core的GitHub主页上报告了一个问题，声称垃圾收集器（GC）“没有收集垃圾”，这似乎使其失去了作用。根据原始创建者的描述，内存会在每次请求后持续增长，使他们认为问题出在GC上。

为了帮助.NET开发者更好地理解他们的应用程序，我们需要深入理解ASP.NET Core中的内存管理工作原理，如何检测内存相关问题，并避免常见的错误。让我们一起探索这个项目——《ASP.NET Core中的内存管理和模式》。

ASP.NET Core中的垃圾收集机制

GC为堆分配段，每个段是一个连续的内存范围。根据对象的生命周期，将它们分为0、1或2代。较低的代号意味着更频繁地尝试释放不再被应用引用的对象的内存。短期生存的对象，如Web请求期间引用的那些，通常会保持在第0代。然而，应用级单例可能会移动到第1代甚至第2代。

当ASP.NET Core应用启动时，GC会为初始堆段预留一些内存，并在运行时加载时提交一小部分，这是为了性能考虑，以确保堆段可以在连续的内存中。

重要提示： ASP.NET Core进程会在启动时预先分配大量内存。

显式调用GC

要手动触发GC，执行GC.Collect()。这将触发第2代的垃圾回收，并包括所有下代。这通常只用于调查内存泄漏，以确保在测量之前GC已经从内存中删除了所有悬挂的对象。

注意： 应用程序通常不需要直接调用GC.Collect()。

分析应用程序的内存使用情况

专门的工具可以帮助分析内存使用：

计数对象引用
测量GC对CPU的影响
测量每个世代的空间使用情况

但为了简化，本文不会使用这些工具，而是展示一些应用内实时图表。

对于深入分析，请阅读以下使用Visual Studio .NET的示例：

检测内存问题

大多数情况下，我们使用任务管理器中的内存指标来获取ASP.NET应用使用的内存量。这个值表示ASP.NET进程使用的内存，包括应用的存活对象和其他内存消费者，如本机内存使用。

如果看到这个值无限增加，这是一个内存泄漏的线索，但它不能说明具体是什么原因。接下来的部分将介绍特定的内存使用模式并解释它们。

运行应用

完整的源代码可在GitHub上找到：https://github.com/sebastienros/memoryleak

一旦启动，应用会显示一些内存和GC统计信息，并每秒自动刷新页面。特定API端点执行特定的内存分配模式。

为了测试这个应用，只需启动它。你可以看到分配的内存不断增加，因为显示这些统计数据正在分配自定义对象。GC最终会运行并清理它们。

该页面显示两个内存使用值：

分配：由托管对象占用的内存
工作集：进程（如任务管理器所示）使用的总物理内存（RAM）

短暂对象

以下API创建一个10KB的String实例并将其返回给客户端。每个请求都会在内存中分配一个新的对象并写入响应。

注意： 字符串在.NET中以UTF-16字符存储，所以每个字符在内存中占用2个字节。

[HttpGet("bigstring")]
public ActionResult<string> GetBigString()
{
    return new String('x', 10 * 1024);
}

通过相对较小的负载（5K RPS）生成以下图形，以便了解内存分配是如何受到GC影响的。

在这个例子中，一旦内存分配达到约300 MB的阈值，大约每两秒钟就会有一次第0代的垃圾收集。工作集稳定在500 MB左右，CPU使用率低。

这个图展示了在相对低的请求吞吐量下，内存消耗是如何非常稳定的，达到了GC选择的数量。

当负载增加到机器能处理的最大吞吐量时，产生的图表如下：

有一些值得注意的点：

收集动作更为频繁，每秒多次
现在有第1代的收集，这是因为我们在同一时间间隔内分配了很多第1代对象
工作集仍保持稳定

我们可以看到，只要CPU没有过度使用，垃圾收集就能处理大量的分配。

工作站GC与服务器GC

.NET垃圾收集器可以工作在两种不同的模式下：工作站GC和服务器GC。根据其名称，它们优化了不同工作负载。ASP.NET应用默认使用服务器GC模式，而桌面应用使用工作站GC模式。

要强制我们的Web应用使用工作站GC，我们可以在项目文件（.csproj）中设置ServerGarbageCollection参数。这将需要重新构建应用。

    <ServerGarbageCollection>false</ServerGarbageCollection>

也可以通过在已发布应用的runtimeconfig.json文件中设置System.GC.Server属性。

以下是5K RPS下的工作站GC的内存概况图。

差异是显著的：

工作集从500MB下降到70MB
GC每秒多次执行第0代收集，而不是每隔两秒一次
GC阈值从300MB降低到10MB

在典型的Web服务器环境中，CPU资源比内存更重要，因此使用服务器GC更适合。然而，某些服务器场景可能更适合工作站GC，例如在高密度主机上的多个Web应用，其中内存成为稀缺资源。

注意： 在只有一个核心的机器上，GC模式总是工作站模式。

长期引用

尽管垃圾收集器在防止内存增长方面做得很好，但如果对象仅被用户代码保留在活动状态，GC就无法释放它们。如果这种类型的对象所占用的内存不断增长，称为托管内存泄漏。

以下API创建一个10KB的String实例并将其返回给客户端。与第一个示例的区别在于，这个实例被静态成员引用，这意味着它永远不会可供收集。

private static ConcurrentBag<string> _staticStrings = new ConcurrentBag<string>();

[HttpGet("staticstring")]
public ActionResult<string> GetStaticString()
{
    var bigString = new String('x', 10 * 1024);
    _staticStrings.Add(bigString);
    return bigString;
}