web*_*oob 18 .net asp.net memory-leaks memory-management
我有一个ASP.NET网站,将在3-4天内使用大约2GB的物理内存,这对我来说听起来真的很糟糕.目前,我已经配置IIS以在达到500mb时重新启动应用程序池进程.我想尝试找出问题所在.
在.NET中创建对象的新实例时,我的印象是它不需要被释放,因为.NET垃圾收集器会为我执行此操作.
是这种情况还是这可能是我遇到问题的原因之一?
Ste*_*ven 17
.NET将非常有效地为您管理垃圾收集.虽然在实现IDisposable它的类型上调用Dispose方法是明智的,但这可能不是你的问题.由于很多原因,.NET中可能发生内存泄漏.以下是一些:
我希望这会给你一些关于在哪里看的想法.
更新:您应该观看有关ASP.NET调试的视频.
更新2:关于您对我的回答的评论如下.CLR将收集所有托管内存,因此new将使用您创建的所有对象进行收集.从这个意义上讲,对象是否实现并不重要IDisposable或不.但是,有很多时候您需要直接或间接使用本机资源(例如文件句柄,图形句柄,数据库连接,使用本机-thus非托管内存).CLR不知道如何释放这些资源.因为这个.NET有终结器的概念.终结器是类的开发人员可以实现的虚拟方法.执行此操作时,CLR将在该类型的实例未被引用之后以及在收集之前调用此方法.终结器通常包含释放这些资源的逻辑.换句话说,当类型需要本机资源时,它通常会有一个终结器方法,允许类型释放这些资源.
关于CLR怎么样,故事在这里结束.CLR没有具体处理实现该IDisposable接口的对象.然而,.NET垃圾收集器本质上是不确定的.这意味着您不知道它何时运行以及它是否运行.这意味着在清理本机资源之前可能需要很长时间(因为终结器只会在收集后调用).但是,对于许多资源,一旦完成它们就必须立即释放它们.例如,当您不关闭数据库连接或通过System.Drawing命名空间在.NET中使用GDI +时,您往往会快速耗尽数据库连接.
出于这个原因,IDisposable引入了界面.同样,CLR和垃圾收集器不会查看此接口.它是类型与其用户之间的契约,允许其用户直接释放对象的底层资源.在正常设计中,对象的终结器和对象的Dispose方法都将调用将释放这些资源的相同私有或受保护方法.当一个类型实现时IDisposable,明智的做法Dispose是在完成它时调用它的方法或将对象包装在using语句中以允许本机资源的释放是确定性的.
所以回到你的问题.GC将收集所有托管对象,但本地资源不会.因此,类型可以实现终结器方法,并且这些对象通常也将实现IDisposable接口.调用Dispose它们将明确地直接释放这些本机资源.
我希望这是有道理的.
您的高内存使用可能有很多原因,但.NET中的垃圾收集是一个非常精确的事情.也就是说,它为你做了很多,但有时候并没有你想象的那么多.
具体来说,它只能清理没有活动引用的对象,所以如果你已经完成了一个类,但是某些东西仍然有引用它,你将需要删除该引用,以便GC可以恢复该内存为了你.此外,如果您有任何非活动的打开连接(例如,对数据库或其他东西),请不要忘记关闭并处置它们.通常,我们将这些对象包装在这样的using块中:
using(SqlConnection conn = new SqlConnection(myConnString))
{ ...rest of code here }
Run Code Online (Sandbox Code Playgroud)
这将自动关闭并处理连接.这是作为try ... finally块实现的,因此即使在using块中抛出异常,连接也将被关闭.
除此之外,答案是"个人资料,个人资料,个人资料",直到找到你的泄漏/瓶颈/其他.
| 归档时间: |
|
| 查看次数: |
17214 次 |
| 最近记录: |