浅谈线程池（上）：线程池的作用及CLR线程池

核心提示： 这两个接口的作用和使用方式应该足够明显了（不理解的话可以查阅MSDN），其中workerThreads参数便是CLR线程池的最小线程数，浅谈线程池（上）：线程池的作用及CLR线程池(5)，而completionPortThreads涉及到我们下次要讨论IO线程池，在此就不多作展开了，且有着足够的

这两个接口的作用和使用方式应该足够明显了（不理解的话可以查阅MSDN），其中workerThreads参数便是CLR线程池的最小线程数，而completionPortThreads涉及到我们下次要讨论IO线程池，在此就不多作展开了。除了设置和读取CLR最小线程数的方法之外，ThreadPool还包含这些接口：

public　static　class　ThreadPool　　
{　　
　　　　public　static　void　GetMaxThreads(out　int　workerThreads,　out　int　completionPortThreads);　　
　　　　public　static　bool　SetMaxThreads(int　workerThreads,　int　completionPortThreads);　　
　　　　public　static　void　GetAvailableThreads(out　int　workerThreads,　out　int　completionPortThreads);　　
}　

值得注意的是，无论是设置还是获取到的这些数值，都与处理器数量没有任何关系了。也就是说，在一台2 * 2CPU的机器上运行一个普通的.NET应用程序时：

调用GetMaxThreads方法将获得1000，表示CLR线程池最大容量为1000（250 * 4），而不是250。

调用SetMinThreads并传入100，表示CLR线程池所拥有的最小线程数量为100，而不是400（100 * 4）。

对于CLR线程池的作用的简单描述就暂时先到这里了。如果您还有什么疑问请提出，我会加以补充。

注1：严格说来，Thread对象和系统线程对应关系还有些细节上的考虑。例如，Thread对象只有当真正Start了之后，CLR才会创建一个操作系统线程与它绑定。

注2：ExecutionContext是个很重要且很有用的对象，例如，WinForms或WPF的异步任务中操作界面元素抛出异常该怎么办呢？

注3：使用Windows API或Thread类创建线程时可以指定它的栈空间大小，但是CLR线程池中的线程只能使用默认值——不过这个默认值也和托管环境有关，如普通应用程序默认为1MB，而ASP.NET为250KB，这意味着ASP.NET应用程序相对更容易产生Stack Overflow异常。

注4：可惜的是，对于processModel节点的数据，ASP.NET只会读取machine.config中的全局配置信息，这意味着我们不能使用web.config为不同应用程序配置不同的参数。如果我们要实现应用程序级别的配置，那么必须使用ThreadPool类中提供的API进行设置，这点稍后便会提到。

注5：对于这点，您不妨来做一个算术题：线程池内一下子涌入了500个任务，每个任务阻塞或暂停5秒，每个线程占用1MB内存，假设线程池目前为空，且有着足够的容量，此外线程创建速度也足够快，那么在限制及不限制线程创建速度的情况下，完成这些任务需要多少时间和内存空间？