IIS应用程序池和.NET垃圾收集
考虑一个存在连接池内存泄漏问题的 ASP.NET 应用程序（例如，连接未正确关闭）。
回收应用程序池是否会清除连接池（从而允许建立更多连接）？
如果连接保留在内存中直到垃圾收集器将其删除，那么当应用程序池重新启动时是否会发生这种情况（或者它们是否/可以保留）？ 我还了解垃圾收集器也可以随时清理它们，但它们是否仍在使用中并且在重置或应用程序池重新启动之前无法收集？
我正在审查一个系统，其最终目标显然是纠正代码以正确管理连接，并且我试图更多地了解垃圾收集/应用程序池过程。
Consider an ASP.NET application with has a connection pool memory leak problem (where connections are not being closed correctly for example).
Does recycling the application pool clear the connection pool (thus allowing more connections to be made)?
If the connections are left in memory until the Garbage Collector removes them, does this happen when the application pool is restarted (or are/can they left beyond that)? I also understand the Garbage Collector could clean them up at anytime as well, but are they still in use and unable to be collected until a reset or application pool restart?
I'm reviewing a system where the end goal is obviously to have the code corrected to manage the connections correctly, and I'm trying to gain more of an understanding about the garbage collection/application pool process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，回收应用程序池会杀死并重新启动负责运行应用程序的 IIS 进程。 此时所有资源都被释放，因为进程正在退出。
如果进程从未重新启动并且只是泄漏句柄，则垃圾收集器最终将清理它们。 然而，在这种情况发生之前，您可能会耗尽任何正在泄漏的资源的句柄。 这就是为什么在这些对象上调用 Dispose() 很重要（最好通过“using”模式），以便应用程序使用完它们后立即释放资源，而不是在垃圾收集器处理它们时释放资源。
Yes, recycling the app pool kills and restarts the IIS process responsible for running your application. All resources are freed at this point, simply because the process is exiting.
If the process is never restarted and simply leaks handles, the garbage collector will eventually clean them up. However, it's likely that you'll run out of handles for whatever resource is leaking before this happens. This is why it's important to call Dispose() on these objects(preferably by the "using" pattern) so that the resources are freed as soon as the app is done with them and not when the garbage collector gets around to it.
连接池是数据库连接的缓存。 应用程序池是一个（或多个）工作进程。 因此，当您关闭应用程序池时，您将关闭工作进程并启动新的工作进程； 这将导致池被破坏并且连接池中的所有连接被关闭。
如果您不对连接调用 Close 或 Dispose 并依赖垃圾收集器，则连接可能会也可能不会返回到池中。 我认为只有当连接仍然有效并且已达到最大池大小时，它才会被添加回池中。 您可能知道，您永远不应该依赖垃圾收集器来执行此操作。 确保连接已 Dispose 的一个简单方法是使用 using 语句，该语句将在代码块末尾自动调用 Dispose。
在 ADO.NET 2.0 中，提供了以编程方式管理池的新方法：ClearAllPools 和 ClearPool。 这可能会帮助您解决问题，直到您可以修复所有数据访问代码。
A connection pool is a cache of database connections. An application pool is one (or more) worker processes. So, when you shut down the application pool you are shutting down your worker processes and starting up new worker processes; this will result in the pool being destroyed and all connections in the connection pool being closed.
If you do not call Close or Dispose on a connection and rely on the garbage collector then the connection may or may not be returned to the pool. I think it will only be added back to the pool if the connection is still valid and the maximum pool size has been reached. As you probably know, you should never rely on the garbage collector for this. An easy way to ensure the connection is Disposed is to use the using statement which will automatically call Dispose at the end of the code block.
In ADO.NET 2.0 there are new methods to programmatically manage the pools: ClearAllPools and ClearPool. This might help you with your problem until you can fix all of the data access code.