小結： 對于開發者來說幸運的是：線程在asp.net中遠遠比在asp中來的容易。本篇文章中，作者注視線程于asp.net http pipeline中，同時解釋線程在開發者沒有卷入的情況是如何被高效管理的。 本篇文章考慮CLR線程池是如何被asp.net 服務請求使用的，還有池在處理，模型，和應用的機制，覆蓋惡劣IIS5 和IIS6，及它們在請求處理和線程分配的不同。最后，探討了對于需要使用線程的開發者來說，何時和如何使用異步處理在他們的應用中。



在傳統的asp中，開發者面對線程問題之于他們知道應該要做什么要多。因為asp是建立于com之上的，關于元件的線程需求這兒有非常詳細而精確的規范。頁面所使用的元件為了最大效率原因需要置于公寓線程中。相反地，在Session 和應用狀態中的元件需要便捷的環境并且能夠聚合于自由線程集合中，也能夠保護他們的狀態防止被并發的訪問。



如果你查看asp.net的文檔，結果你會發現關于線程需求是如此之少。難道這就意味著所有的線程問題都被解決了并且asp.net開發者可以放心的去開發他們的aspx頁面和NFC沒有混亂在并發問題上？ 不，大多數情況下并不是這樣。



本文中，我將在不增加開發者負擔的情況下，探索http 管道中線程的細節和如何有效的管理線程。同時我將看一下asp.net如何使用CLR 線程池處理服務請求的。



Asp.net中的線程

為了有效的服務多個客戶請求，Web Server 通過使用多個進程或生成多個線程來響應服務請求。Asp.net 沒使用異常和在一個進程中響應請求使用多個線程。基于這個現狀，asp.net開發者不需要關心多線程環境問題。頁面需求響應總是在一個線程中， 并且當有一個新的需求時，一個新的頁面將會創建一個截然不同的實例。應用的不同實例和模型元件總是被響應每一個請求。 然而，理解如何使用線程來響應請求是非常重要的。

開始之際，asp.net使用CLR線程池響應請求。池的大小在機器配置文件中（machine.config），默認被設置為25工作線程 和25個I/O線程：



<processModel enable="true"

&#8226;&#8226;&#8226;

maxWorkerThreads="25"

maxIoThreads="25" />

（待續）