追踪 .NET Windows 服务内存泄漏

Question

在生产中安装 Windows 服务之前，我一直在寻找可以执行的可靠测试，以确保我的代码不包含内存泄漏。 但是，我在网上能找到的只是使用任务管理器查看已用内存或一些付费的内存分析工具。

据我了解，查看任务管理器并没有太大帮助，也无法确认内存泄漏（以防万一）。

1. 如何确认是否存在内存泄漏？

2. 有没有免费的工具可以找到内存泄漏的根源？

注意：我正在使用 .Net Framework 4.6 和 Visual Studio 2015 社区

Answer 1

虽然托管代码意味着没有直接的内存管理，但您仍然需要管理您的实例。这些实例“声称”内存。而这一切都与这些实例的使用有关，在您不希望它们存在时让它们保持活力。

只是众多示例之一：一次性类的错误使用会导致大量实例占用内存。对于 Windows 服务，缓慢但稳定地增加实例最终会导致大量内存使用。

是的，有一个分析内存泄漏的工具。它不是免费的。不过，您或许能够在 7 天试用期内发现您的问题。

我建议在.NET Memory Profiler 上抢夺。

在开发过程中分析内存泄漏非常棒。它使用快照的概念来比较新实例、已处置的实例等。这对了解您的服务如何使用其内存有很大帮助。然后，您可以更深入地了解为什么新实例会被创建或保持活动状态。

是的，您可以测试以确认是否引入了内存泄漏。 但是，开箱即用，这并不是很有用。这是因为没有人能够预料到运行时会发生什么。该工具可以分析您的应用程序的常见问题，但这不能保证。

但是，您可以使用此工具将内存消耗集成到您的单元测试框架中，例如 NUnit 或 MSTest。

Answer 2

你可以试试免费的 Memoscope 内存分析器

https://github.com/fremag/MemoScope.Net

我不同意您可以信任任务管理器来检查您是否有内存泄漏。垃圾收集器的问题在于它可以根据启发式方法决定在内存达到峰值后保留内存而不将其返回给操作系统。您可能有 2 GB 的提交大小，但其中 90% 可以是免费的。

您应该使用VMMAP 在测试期间检查您的进程包含什么类型的内存。您不仅有托管堆，还有非托管堆、私有字节、堆栈（线程泄漏）、共享文件等等需要跟踪。

VMMap 还具有命令行界面，可以定期创建快照，以便以后检查。如果您有内存增长，您可以根据泄漏类型不同的调试工具方法找出泄漏了哪种类型的内存。

Answer 3

当然，内存分析器是第一种尝试的工具，但它只会告诉您实例是否不断增加。您仍然想知道它们增加是否正常。此外，一旦您确定某些实例无缘无故地不断增加（意味着您有泄漏），您将想准确知道哪些调用树导致它们的分配，以便您可以对分配它们的代码进行故障排除和修复它，以便最终释放它们。

以下是我多年来在处理此类问题时收集的一些知识：

1. 尽可能将您的服务作为常规可执行文件进行测试。尝试将服务作为实际服务进行测试只会让事情变得过于复杂。

2. 养成在你正在做的事情范围结束时明确撤消你所做的一切的习惯。例如，如果您为某个被观察者的事件注册了一个观察者，则应该始终在某个时间点（观察者或被观察者的处置？）取消注册它。理论上，垃圾收集应该通过收集相互连接的观察者和被观察者的整个图来解决这个问题，但在实践中，如果你不改掉忘记撤消所做的事情的习惯，就会导致内存泄漏。

3. 尽可能使用IDisposable，如果有人忘记调用Dispose()，让你的析构函数报告。更多关于这个方法的信息在这里：Mandatory disposal vs. the "Dispose-disposing" abomination 披露：我是那篇文章的作者。

1234563 /p>

4. 如果某个类的实例出现泄漏，请使用以下技巧找出导致它们分配的精确调用树：在该类的构造函数中，分配一个异常对象而不抛出它，获取堆栈跟踪的异常，并存储它。如果您稍后发现此对象已泄漏，则您有必要的堆栈跟踪。只是不要对太多对象执行此操作，因为分配异常并从中获取堆栈跟踪非常慢，只有 Microsoft 知道原因。

Answer 4

你可以使用任务管理器。 GC 应用程序可能会泄漏内存，它会在那里显示。

但是……

免费工具——“.Net CLR profiler”

有一个免费工具，它来自 Microsoft，非常棒。这是所有泄漏引用的程序都必须使用的。搜索 MS 的网站。

泄漏引用意味着您忘记将对象引用设置为 null，或者它们永远不会离开作用域，这在垃圾收集语言中发生的可能性几乎与未清除的语言一样 - 列表建立但未清除，事件处理程序指向委托等.

这是内存泄漏的 GC 等价物并且具有相同的结果。这个程序告诉你哪些引用占用了大量内存 - 你会知道它是否应该这样，如果不是，你可以找到它们并解决问题！

它甚至可以很酷地显示哪些对象分配了哪些内存（因此您可以跟踪错误）。如果您需要解释，我相信有这方面的 youtube。

Wikipedia page with download links...

注意：您可能必须将您的应用程序而不是作为服务运行才能使用它。它首先启动，然后运行您的应用程序。您可以使用 TopShelf 或仅将胆量放入一个 dll 中，该 dll 从实现服务集成（服务主机模式）的 EXE 运行。

Answer 5

如果您使用实体框架和 DI 模式，也许使用 Castle Windsor，您很容易出现内存泄漏。

要做的主要事情是尽可能使用 using( ){ } 语句来自动将对象标记为已释放。

此外，您希望在仅读取而不写入的实体框架上关闭自动跟踪。最好隔离您的写入，此时使用 using() {}，获取 dbContext（启用跟踪），写入您的数据。

如果您想调查堆上的内容。我用过的最好的工具是 RedGate ANTS http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/solving-memory-problems/getting-started 不便宜，但很管用。

但是，尽可能使用 using() {} 模式（不要创建静态或单例 DbContext，也不要在大规模更新循环中拥有一个上下文，尽可能频繁地处理它们！ ) 那么你会发现内存通常不是问题。

希望这会有所帮助。

Answer 6

我不会说垃圾收集器是万无一失的。有时它会在不知不觉中失败，而且它们并不是那么直截了当。内存流是内存泄漏的常见原因。您可以在一个上下文中打开它们，它们甚至可能永远不会关闭，即使使用情况被包装在 using 语句中（一次性对象的定义应该在其使用超出范围后立即清理）。如果您因内存不足而遇到崩溃，Windows 会创建您可以筛选的转储文件。

enter link description here

这绝不是有趣或简单的，而且相当乏味，但它往往是你最好的选择。

容易造成内存泄漏的常见区域是使用 System.Drawing dll、内存流以及您正在执行一些严重的多线程的任何内容。

Answer 7

除非您处理的是非托管代码，否则我可以大胆地说您不必担心内存泄漏。托管代码中的任何未引用对象都将被垃圾收集器删除，并且在 .net 框架中发现内存泄漏的可能性我会说你应该被认为非常幸运（好吧，不幸）。您不必担心内存泄漏。

但是，如果从不释放对对象的引用，您仍然会遇到内存使用量不断增长的情况。例如，假设您保留了一个内部日志结构，并且您只是不断地将条目添加到日志列表中。那么每个条目仍然有来自日志列表的引用，因此永远不会被收集。

根据我的经验，您绝对可以使用任务管理器作为您的系统是否存在日益严重的问题的指标；如果内存使用率持续上升，你就知道你有问题。如果它增长到一个点但最终收敛到某个大小，则表明它已达到其操作阈值。

如果您想更详细地了解托管内存使用情况，可以下载 Microsoft 开发的进程资源管理器here。它仍然很生硬，但它提供了比任务管理器更好的统计视图。