线程处理对于IIS5和IIS6是不同的是不同的，我会简短地讨论一下这个问题。对于来的每一个请求，一个新的实例就会被创建，为了避免过于频繁的分配应用和模块，每一个应用域维护了应用和模块的池。每个应用池的最大值是和线程池的大小一致的，因此默认上来说，上限为25个工作进程可以被并发处理，每一个有自己的应用和模块集合。图1显示了asp.net 工作进程的一个快照。这中情景下，有两个激活的应用在工作进程中，每个应用独立于自己的应用域中。每一个应用目前处理两个请求，并且每一个使用了两个来自于CLR 池的线程来响应这些请求。
图1 线程和池
这种结构的几个特征可能会影响你构建asp.net应用。首先，应用和模块多次被创建实例意味着你永远不要依赖字段或其它状态，以为它们不能在跨越多个请求中被共享，正如你可以想到的那样。作为替代，可以使用状态库一个状态，例如，使用程序范围的cache， session状态，应用状态，或者每一个请求的集合（来自HttpCntext）。另外在恰当同步的情况下你也可以使用静态数据。
默认上来说，大部分用来响应请求的处理者是不使用池的。你可以使用池处理者，甚至控制池每一个基于IsResusable of IHttpHandler 的处理者，但是只有被隐式地做池的处理者才能作为客户化处理者（自己写的没有指定的处理工厂）。PageHandlerFactory 没有实现池，SimpleHandlerFactory 也是如此，它的实例是以 .ashx-defined 的处理者。典型的来说，每一个请求就会分配一个新的恰当的处理者对象，请求结束后，该处理者对象就会完全被丢弃。