一个“内存泄漏”的解剖学

所有的内存泄漏都可以通过程序终止来解决。

如果泄漏的内存足够多，操作系统可能会决定代表您解决这个问题。

我会同意Bernard在.net中关于内存泄漏的定义。

您可以对应用程序进行性能分析，查看其内存使用情况，并确定如果它在不应该使用大量内存时正在管理大量内存，则可以说它存在泄漏问题。

从托管代码方面来看，我敢肯定一旦进程被终止/移除，泄漏问题就会消失。

非托管代码是自己的一种形态，如果其中存在泄漏问题，它将遵循标准的内存泄漏定义。

请注意，.NET有两个堆，其中一个是大对象堆。我认为大约85k或更大的对象会被放在这个堆中。这个堆具有不同于常规堆的生存期规则。
如果您正在创建大型内存结构(Dictionary或List)，最好查找确切的规则。
至于在进程终止时回收内存，除非您运行Win98或其等效版本，否则所有内容都将在终止时释放回操作系统。唯一的例外是跨进程打开并且另一个进程仍然拥有该资源的事物。
COM对象可能有些棘手。如果始终使用IDispose模式，则会很安全。但是我遇到过一些实现IDispose的互操作程序集。关键在于在完成后调用Marshal.ReleaseCOMObject。COM对象仍然使用标准的COM引用计数。

我认为.Net Memory Profiler在查找.Net中的内存泄漏时非常有帮助。它不像Microsoft CLR Profiler那样免费，但在我看来更快且更直接。

一个定义是：无法释放不可访问的内存，在分配过程执行期间不能再分配给新进程。通常可以通过使用GC技术进行治疗或由自动化工具检测到。

欲获取更多信息，请访问http://all-about-java-and-weblogic-server.blogspot.in/2014/01/what-is-memory-leak-in-java.html。