小结： 对于开发者来说幸运的是：线程在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"
•••
maxWorkerThreads="25"
maxIoThreads="25" />
（待续）
