当首次从DotNet应用程序请求一个aspx页面时，我了解该应用程序的一个appdomain被创建，并且所需的程序集被加载到该appdomain中，并且该请求将被提供。
现在，如果web.config文件或bin文件夹的内容等被修改，则appdomain将被“回收”。
我的问题是，在回收过程结束时，appdomain将加载程序集并准备好为下一个请求服务？或者必须请求页面来触发程序集加载？
解决方法
@H_403_8@ 好吧，我认为线程得到了顺利的最终结论，但最后，它是否则。我会尝试回答这个问题，基于我的理解，并利用我刚刚在其他网站阅读的。
首先，我自己尝试避免除了应用程序池之外的术语“回收”，因为这可能会让人感到困惑。现在，进行处理，池和AppDomain，我看到的图片如下：
简而言之，应用程序池是由称为W3WP.exe(也称为工作进程)的进程维护和运行的内存区域。回收应用程序池意味着将该进程关闭，从内存中删除它，然后创建一个全新的工作进程，并分配一个新分配的进程ID。
关于应用程序域，我认为它是内存区域的子集，在上述区域内扮演容器的角色。换句话说，在这种情况下，内存中的进程W3WP.exe是用于存储子集区域的应用程序的宏内存区域，称为应用程序域。尽管如此，存储器中的一个进程可以存储不同的应用程序域，每个应用程序域被分配为在给定应用程序池内运行。
关于回收，正如我最初所说，这是我自己只保留应用程序池。对于AppDomains，我喜欢使用术语“重新启动”，以避免误解。基于此，重新启动AppDomain意味着启动具有新添加的设置的给定应用程序，例如刷新现有配置。这发生在存储器的子区域的边界内，称为AppDomain，其最终位于与相应应用池相关联的进程内。这些新设置可能来自诸如的文件
web.config，
machine.config，
global.asax，
bin目录，
App_Code，
并且可能有其他人。
AppDomain彼此隔离，这是完全有道理的。如果不是这样，如果更改web.config，让我们说，应用程序1，请求回收池，所有其他应用程序分配到该池将重新启动，这是微软和其他任何人都不希望的。
总结我的观点，
>进程(W3WP.exe)
> AppDomain 1
> AppDomain 2
> AppDomain 3
> AppDomain n
n =指定应用程序到由给定W3WP.exe管理的应用程序池的数量
>进程是彼此隔离的内存区域
> AppDomain是在同一进程内彼此隔离的子存储器区域
>全局IIS设置更改可能需要应用程序池循环(杀死和启动一个新的工作进程，W3WP.exe)
>应用程序范围的设置更改AppDomain的关注，并且他们可能会在一些特定文件中的更改后重新启动，如上面的
有关更多信息，我建议：
What causes an application pool in IIS to recycle?
来自巴西！
