我有一个网站，对某些资源拥有排他性的locking。 我使用.NET Application_Start和Application_End事件在适当的时间获取和释放这些资源上的locking。 为了正常工作，我的应用程序在任何时候都只能运行一个实例。
为了解决这个问题，我将Application Pool上的Disable Overlapped Recycle属性设置为True 。 该属性应该确保旧工作进程在新应用程序池被回收时启动之前完全closures。 只要通过IIS手动回收应用程序池，根据任何特定的时间/时间间隔规则自动根据到达的空闲超时的结果或自动进行自动回收，此工作正常。
但是，当网站的web.config更新时，此规则未得到应用 – 新的工作进程在旧的进程closures之前启动。 这会导致不好的事情发生。 我有Disable Recycling for Configuration Changes属性设置为False因为我希望应用程序池回收时更新web.config – 这经常发生在开发过程中。
这是预期的东西，还是在IIS中的错误？ 是我唯一的select设置，以便更改web.config不回收应用程序池？ 我宁愿不这样做，因为我非常确定这会让人们更改configuration，然后忘记回收应用程序池而引起许多麻烦。
更新：
更清楚的是，在旧工作进程closures之前调用新工作进程start事件时，旧工作进程end事件永远不会被调用 – 它不会发生乱序，根本就不会发生。
从此MSDN Post： https ： //blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/
因此，作为代码部署过程的一部分，看起来您的池将在您部署这些更改时进行回收：
立即回收
（ 借用： https ： //stackoverflow.com/questions/302110/what-causes-an-application-pool-in-iis-to-recycle ）