在运行时,我发现我的应用程序使用了非常大的内存..
但似乎我只使用了 3~4 MemoryStream
s,其中一个有时充满了 81 Mb..
其他的主要是20mb、3mb和1mb的容器……
但是应用程序仍然使用 525.xx MB 内存...
我也尝试使用using(...)
语句,但没有任何运气..
所以,我在这里要求最有效的方法来减少内存泄漏。
在运行时,我发现我的应用程序使用了非常大的内存..
但似乎我只使用了 3~4 MemoryStream
s,其中一个有时充满了 81 Mb..
其他的主要是20mb、3mb和1mb的容器……
但是应用程序仍然使用 525.xx MB 内存...
我也尝试使用using(...)
语句,但没有任何运气..
所以,我在这里要求最有效的方法来减少内存泄漏。
在托管 .NET 应用程序中,通常不会出现原始意义上的内存“泄漏”,除非您正在分配非托管资源句柄并且没有正确处理它们。但这听起来不像你在做什么。
更有可能的是,您持有对不再需要的对象的引用,这使内存“活动”的时间比您预期的要长。
例如,如果您将 5MB 的数据放入内存流中,然后将该内存流分配给静态字段,那么 5MB 将在应用程序的生命周期内永远不会消失。当您不再需要它指向的内容时,您需要将 null 分配给引用内存流的静态字段,以便垃圾收集器释放并回收该 5MB 内存。
同样,局部变量在函数退出之前不会被释放。如果您分配大量内存并将其分配给局部变量,然后调用另一个运行数小时的函数,则局部变量将始终保持活动状态。如果您不再需要该内存,请将 null 分配给局部变量。
您如何确定您的应用程序存在内存泄漏?如果您正在查看任务管理器显示的进程虚拟内存分配,那不是很准确。应用程序的内存管理器可能会从操作系统分配大块内存,并在内部释放它们以供应用程序内的其他用途使用,而不会将它们释放回操作系统。
使用常识实践。酌情调用 dispose 或 close 并在不再需要变量内容时将 null 分配给变量。
仅仅因为垃圾收集环境会让你变得懒惰并不意味着你不应该注意代码中的内存分配和释放模式。
您对内存泄漏的定义似乎不寻常......以下代码将产生您正在观察的效果,但它很少称为内存泄漏:
var data = new byte[512*1024*1024];
data = null;
但是您实际上可能有合法的泄漏。内存分析器很容易显示它们,但可以通过代码审查来追踪巨大的。如果您已经知道您有少量的内存流 - 检查您是否通过存储在某个列表或简单地存储在成员变量中来保持它们处于活动状态。还要检查您的大型阵列是否因类似原因而无法存活。