線程處理對于IIS5和IIS6是不同的是不同的，我會簡短地討論一下這個問題。對于來的每一個請求，一個新的實例就會被創建，為了避免過于頻繁的分配應用和模塊，每一個應用域維護了應用和模塊的池。每個應用池的最大值是和線程池的大小一致的，因此默認上來說，上限為25個工作進程可以被并發處理，每一個有自己的應用和模塊集合。圖1顯示了asp.net 工作進程的一個快照。 這中情景下，有兩個激活的應用在工作進程中，每個應用獨立于自己的應用域中。每一個應用目前處理兩個請求，并且每一個使用了兩個來自于CLR 池的線程來響應這些請求。



圖1 線程和池

這種結構的幾個特征可能會影響你構建asp.net應用。首先，應用和模塊多次被創建實例意味著你永遠不要依賴字段或其它狀態，以為它們不能在跨越多個請求中被共享，正如你可以想到的那樣。作為替代，可以使用狀態庫一個狀態，例如，使用程序范圍的cache， session狀態，應用狀態，或者每一個請求的集合（ 來自HttpCntext）。另外在恰當同步的情況下你也可以使用靜態數據 。

默認上來說，大部分用來響應請求的處理者是不使用池的。你可以使用池處理者，甚至控制池每一個基于IsResusable of IHttpHandler 的處理者，但是只有被隱式地做池的處理者才能作為客戶化處理者（自己寫的沒有指定的處理工廠）。PageHandlerFactory 沒有實現池，SimpleHandlerFactory 也是如此，它的實例是以 .ashx-defined 的處理者。典型的來說，每一個請求就會分配一個新的恰當的處理者對象，請求結束后，該處理者對象就會完全被丟棄。