我想知道AppDomain回收的究竟是什麼？ 當第一次從DotNet應用程序請求aspx頁面時，我明白該應用程序的appdomain已創建，並且所需的程序集將加載到該appdomain中，並且該請求將被提供。 現在，如果web.config文件或bin文件夾等內容被修改，appdomain將被「回收」。 我的問題是，在回收過程結束時，appdomain是否會加載程序集並準備好提供下一個請求？或者必須要求頁面觸發組件加載？AppDomain回收究竟是什麼
嗯，我認爲線程正在順利得出最終結論，但最終，否則。
我會盡力回答根據我的理解，並利用我剛纔在其他網站閱讀有關的問題。
首先，我自己儘量避免比應用程序池的其他術語的循環，因爲這可能會使人感到困惑。現在，進入進程，池和AppDomain，我看到如下圖：
應用程序池是簡稱爲W3WP.exe的進程維護並運行的內存區域，又稱工作進程。回收應用程序池意味着將該進程關閉，將其從內存中刪除，然後使用新分配的進程ID創建全新的工作進程。
關於應用程序域，我把它看作是存儲區域的子集，在前面提到的承擔容器角色的區域內。換句話說，在這種情況下，內存中的進程W3WP.exe是存儲子集區域的應用程序的宏內存區域，稱爲應用程序域。儘管如此，內存中的一個進程可能會存儲不同的應用程序域，一個用於分配給在給定應用程序池內運行的每個應用程序。
說到回收，正如我最初告訴的那樣，這是我自己只爲應用程序池預留的東西。對於AppDomains，我更喜歡使用術語「重新啓動」，以避免誤解。基於此，重新啓動AppDomain意味着通過新添加的設置（例如刷新現有配置）重新啓動給定的應用程序。這發生在該內存子區域的邊界內，稱爲AppDomain，最終位於與相應應用程序池關聯的進程內。這些新的設置可能來自文件，如
web.config中， machine.config中， Global.asax的， Bin目錄， App_Code文件，
，並有可能是別人。
AppDomain是相互隔離的，這是完全意義上的。如果不是這樣，如果更改爲web.config（比如應用程序1），請求回收池，則分配給該池的所有其他應用程序都將重新啓動，但Microsoft和其他人絕對不希望這樣做。
總結我的觀點，
N =轉讓的申請，以通過給定W3WP.EXE所管理的應用程序池數量
如需進一步信息，我建議：
What causes an application pool in IIS to recycle?
來自巴西的問候！
看看這個 - 這或許可以解釋它：
一般。由於編譯和創建AppDomain，ASP.NET網站上所謂的「第一次打擊」通常需要更長的時間。
當你部署網站 - 確保使用「發佈網站」功能，在Visual Studio中，預編譯您的網站。那麼「第一擊」的懲罰就會減少。並記住將配置設置爲Release，而不是調試！
如果您的頁面是「可更新的」，它們必須在使用前進行編譯。這意味着，是的，在首次請求時，程序集被加載，編譯並準備好訪問。每當這些文件被改變時（甚至一些病毒軟件可以通過改變文件的修改日期來觸發這個！），appdomain被回收。
您可以將您的Web應用程序配置爲不可更新。所有東西都被編譯成DLL，並且你不會在虛擬目錄中看到任何.ASPX或.CS文件。它使你的代碼難以更新（需要在你的網頁上添加一些額外的文本？重新編譯時間！），但它增加了你的web應用程序的可用性。
但是，如果任何文件被更改，這仍然不會阻止您的Web應用程序被回收。例如，如果你編輯web.config，你的appdomain即使編譯它也會回收。
回收關閉託管appdomain的進程。你會注意到當你回收它時PID會改變。
卸載的AppDomin簡單地卸載所有的應用程序域的組件，然後可以重新使用的。
要記住的重要一點是，一旦CLR加載到進程中，它不能被刪除。因此，如果您需要在CLR加載完成後立即執行某些操作，那麼只需卸載AppDomain將無濟於事，因爲CLR不會被重新加載。
而且不是IIS不是能承載的AppDomain唯一的過程 - 任何處理就可以了，你不要總想殺人的整個過程只需卸載程序集。
（+1）感謝您的鏈接。在這篇文章中有一個與苔絲的帖子有關的鏈接，這是必須看到的。 – 2010-04-04 12:42:35