【问题标题】:IIS application pool and .NET garbage collectionIIS 应用程序池和 .NET 垃圾收集
【发布时间】:2010-11-12 05:27:44
【问题描述】:

假设一个 ASP.NET 应用程序存在连接池内存泄漏问题(例如,连接未正确关闭)。

回收应用程序池是否会清除连接池(从而允许建立更多连接)?

如果连接一直保留在内存中,直到垃圾收集器将其删除,那么在重新启动应用程序池时是否会发生这种情况(或者它们是否/可以超出该范围)?我也了解垃圾收集器也可以随时清理它们,但它们是否仍在使用中并且在重置或应用程序池重新启动之前无法收集?

我正在审查一个系统,其最终目标显然是纠正代码以正确管理连接,并且我正在尝试更多地了解垃圾收集/应用程序池过程。

【问题讨论】:

    标签: asp.net memory-leaks iis-6 connection-pooling application-pool


    【解决方案1】:

    是的,回收应用程序池会终止并重新启动负责运行您的应用程序的 IIS 进程。此时所有资源都被释放,仅仅是因为进程正在退出。

    如果进程从未重新启动并且只是泄漏句柄,垃圾收集器最终会清理它们。但是,在这种情况发生之前,您可能会用完任何资源泄漏的句柄。这就是为什么在这些对象上调用 Dispose() 很重要的原因(最好通过“使用”模式),以便在应用程序完成它们后立即释放资源,而不是在垃圾收集器处理它时释放资源。

    【讨论】:

      【解决方案2】:

      连接池是数据库连接的缓存。应用程序池是一个(或多个)工作进程。因此,当您关闭应用程序池时,您正在关闭您的工作进程并启动新的工作进程;这将导致连接池被销毁并关闭连接池中的所有连接。

      如果您不对连接调用 Close 或 Dispose 并依赖垃圾收集器,则连接可能会或可能不会返回到池中。我认为只有在连接仍然有效并且达到最大池大小时才会将其添加回池中。您可能知道,您永远不应该为此依赖垃圾收集器。确保连接被 Disposed 的一种简单方法是使用 using 语句,该语句将在代码块末尾自动调用 Dispose。

      在 ADO.NET 2.0 中有以编程方式管理池的新方法:ClearAllPools 和 ClearPool。在您修复所有数据访问代码之前,这可能会帮助您解决问题。

      【讨论】:

      • 对我来说幸运的是,我不会成为必须进行修复的人!真正的问题是在应用程序中过度使用数据读取器...没有 try/catch/finally 块,所以如果在 dispose 代码从未运行并且连接被用完时发生错误...
      • 听起来就是这样......这很有趣/可悲的是,同样的错误一次又一次地出现。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多