保持 .NET 应用程序内存健康的 6 个最佳实践
保持 .NET 应用程序内存健康的 6 个最佳实践
大型 .NET 应用程序中的内存问题是某种无声的杀手。有点像高血压。你可以长期吃垃圾食品而忽略它,直到有一天你面临严重的问题。对于 .NET 程序,该严重问题可能是高内存消耗、主要性能问题和彻底崩溃。在这篇文章中,您将看到如何将我们的应用程序的血压保持在健康水平。
你怎么知道你的内存使用情况是否健康?你需要做什么来保持它的健康?这正是本文要讨论的内容。我们将介绍 6 种最佳做法,以保持内存健康并在出现问题时检测问题。您还将看到优化垃圾收集并使您的应用程序非常快速的最佳实践。
1. 应尽快收集对象
为了使您的程序快速运行,主要目标是尽快收集对象。要理解为什么它很重要,您需要了解 .NET 的分代垃圾收集器。当使用该new
子句创建对象时,它们是在第 0 代的堆上创建的。那是内存中非常小的空间。如果在有 Gen 0 集合时它们仍然被引用,它们将被提升到 Gen 1。Gen 1 是更大的内存空间。如果它们在有第 1 代集合时仍被引用,则将它们提升到第 2 代。
Gen 0 集合是最频繁的并且非常快。Gen 1 集合涵盖 Gen 0 内存空间和 Gen 1 内存空间,并且它们更昂贵。Gen 2 集合包括整个内存空间,包括大对象堆 (LOH)。它们非常昂贵。GC 已优化为具有许多 Gen 0 集合、较少的 Gen 1 集合和很少的 Gen 2 集合。但是,如果您有许多对象被提升到更高代,那么您将产生相反的效果。这会导致内存压力[1](又名 GC 压力)和性能不佳。
顺便说一下,新对象的分配非常便宜。您唯一需要担心的是集合。
那么如何在低代收集对象呢?很简单,只需确保不会尽快引用它们即可。有些对象,比如单例,必须永远在内存中。没关系,它们通常是不会消耗大量内存的服务。
2. 使用缓存……但要小心
根据定义,像缓存这样的机制很麻烦。这些是长期存在的临时对象,可能会升级到第 2 代。虽然这对 GC 压力不利,但通常值得付出代价,因为缓存确实可以帮助提高性能。但你必须密切关注它。
缓解部分内存压力的一种方法是使用可变缓存对象。这意味着不是替换缓存对象,而是更新现有对象。这意味着 GC 提升对象和启动更多 Gen 0 和 Gen 1 收集的工作更少。
这是一个例子。假设您正在缓存来自在线杂货店的库存商品。您有一个缓存机制来存储经常查询的项目的价格和数据。就像那些会导致高血压的冷冻比萨饼。假设每 5 分钟您必须使缓存无效并重新查询数据库,以防细节发生变化。因此,在这种情况下,不是创建新Pizza
对象,而是更改现有对象的状态。
3. 留意 GC 中的时间百分比
如果您想知道垃圾收集对执行时间的影响有多大,这很容易做到。简单看看性能计数器.NET CLR Memory | % GC 时间。这将显示垃圾收集器使用了百分之多少的执行时间。有许多工具可以查看性能计数器。在 Windows 中,您可以使用 PerfMon。在 Linux 中,您可以使用dotnet-trace[2]。要了解更多信息,请查看我的文章Use Performance Counters in .NET to measure Memory, CPU, and Everything[3]。
我将给您一些神奇的数字,但请注意这些数字,因为一切都有其自身的背景。对于大型应用程序,10% 的 GC 时间可能是一个健康的百分比。GC 中 20% 的时间处于临界状态,任何更多都意味着您有问题。
4. 留意那些 Gen 2 Collections
除了 GC 中的时间百分比,您应该监控的另一个重要指标是 Gen 2 收集的数量。或者更确切地说是第 2 代收藏的速度。目标是尽可能少地使用它们。考虑到这些是完整的内存堆集合。当 GC 收集所有内容时,它们有效地冻结了应用程序的所有线程。
对于您应该拥有多少 Gen 2 系列,我无法给出一个神奇的数字。但我建议每隔一段时间积极监控这个数字,如果比率上升,那么你可能会添加一些非常糟糕的行为。您可以通过性能计数器.NET CLR Memory |查看该数字。% Gen 2 集合
PerfMon 显示第 2 代集合
5. 监控稳定的内存消耗
考虑应用程序的常规状态。有些事情一直在发生。它可能是一个服务请求的服务器,一个从队列中提取消息的服务,一个有很多屏幕的桌面应用程序。在此期间,您的应用程序不断创建新对象,执行一些操作,然后释放这些对象并返回到正常状态。这意味着从长远来看,内存消耗应该或多或少相同。当然,它可能会在高峰时间或繁重操作期间达到高水平,但一旦完成它应该会恢复正常。
但是,如果您监控了许多应用程序,您可能知道有时内存会随着时间的推移而增加。内存的平均消费缓慢上升到更高的水平,即使它在逻辑上不应该。这种行为的原因几乎总是内存泄漏[4]。这是一个对象不再使用的现象,但由于某种原因,它仍然被引用,因此从未被收集。
当一个操作导致对象泄漏时,每个这样的操作都会消耗更多的内存。随着时间的推移,记忆力上升。当足够的时间过去时,内存接近其极限。在 32 位进程中,该限制为 4GB。在 64 位进程中,它取决于机器约束。当我们如此接近极限时,垃圾收集器就会恐慌。它开始为每个其他分配触发全内存第 2 代收集,以免内存不足。这很容易使您的应用程序变慢。当更多的时间过去时,内存确实达到了它的极限,并且应用程序会因灾难性的OutOfMemoryException
. 你有它 - 相当于心脏病发作。
为了确保您不会达到这种状态,我的建议是随着时间的推移主动监控内存消耗。最好的方法是查看性能计数器Process | Private Bytes。您可以使用Process explorer[5]或 PerfMon轻松完成。
6. 定期查找内存泄漏
内存问题的#1 罪魁祸首毫无疑问是内存泄漏。很容易造成它们,它们可以被长期忽视,最终会造成大量损害。在应用程序持续崩溃的阶段修复内存泄漏非常困难。您必须更改可能导致各种回归错误的旧代码。因此,我将为具有健康内存的应用程序添加第二个主要目标:修复并避免内存泄漏。
期望您的团队永远不会引入内存泄漏是不现实的。并且在每次新提交时检查整个应用程序中的内存泄漏是不切实际的。相反,我建议添加每隔一段时间检查内存泄漏的做法,它可能是每周、每月或每季度,具体取决于你的需求。
一种方法是在每次看到内存上升时检查内存泄漏(如提示 #5 中建议的那样)。但问题是内存占用低的泄漏也会导致很多问题。例如,您可能有一些本应收集但仍处于活动状态的对象,并且仍有代码在其中执行,这会导致不正确的行为。
检测和修复内存泄漏的最佳方法是使用内存分析器。在我的文章Demystifying Memory Profilers in C# .NET Part 2: Memory Leaks 中[6]了解如何做到这一点。
要了解哪种设计会导致内存泄漏,请查看我的文章.NET 中可能导致内存泄漏的 8 种方式[7]。
总结
所以你有它,一个健康记忆状态的秘诀。如果您遵循这些建议,您的应用程序将很快并且消耗很少的内存。但说真的,请吃健康的食物和锻炼🙂
References
[1]
内存压力: https://michaelscodingspot.com/avoid-gc-pressure/[2]
dotnet-trace: https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-trace-instructions.md[3]
Use Performance Counters in .NET to measure Memory, CPU, and Everything: https://michaelscodingspot.com/performance-counters/[4]
内存泄漏: https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/[5]
Process explorer: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer[6]
Demystifying Memory Profilers in C# .NET Part 2: Memory Leaks 中: https://michaelscodingspot.com/memory-profilers-for-memory-leaks/[7]
.NET 中可能导致内存泄漏的 8 种方式: https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/
.NET Core实战项目之CMS 第一章 入门篇-开篇及总体规划
【.NET Core微服务实战-统一身份认证】开篇及目录索引
Redis基本使用及百亿数据量中的使用技巧分享(附视频地址及观看指南)
.NET Core中的一个接口多种实现的依赖注入与动态选择看这篇就够了
用abp vNext快速开发Quartz.NET定时任务管理界面