建议78：应避免线程数量过多
在多数情况下，创建过多的线程意味着应用程序的架构设计可能存在着缺陷。经常有人会问，一个应用程序中到底含有多少线程才是合理的。现在我们找一台PC机，打开Windows的任务管理器，看看操作系统中正在运行的程序有多少个线程。
在笔者当前的PC机上，线程数最多的一个应用程序是某款杀毒软件，它一共拥有116个线程数；其次是Windows自身的System进程，当前共有104个线程；第三多的进程是Sqlservr.exe，锐减到了35个线程；剩下还有63个进程，估计它们平均约有10个线程。所以说，大多数应用程序的线程数不会太多。
错误地创建过多线程的一个典型的例子是：为每一个Socket连接建立一个线程去管理。每个连接一个线程，意味着在32位系统的服务器不能同时管理超过1000台的客户机。CLR为每个进程分配的内存会超过1MB。约1000个进程，加上.NET进程启动本身所占用的一些内存，即刻就耗尽了系统能分配给进程的最大可用地址空间2GB。即便应用程序在设计之初的需求设计书中说明，生产环境中客户端数目不会超过500台，在管理这500台客户端时进行线程上下文切换，也会损耗相当多的CPU时间。这类I/O密集型场合应该使用异步去完成（请参考建议71的相关阐述）。
过多的线程还会带来另外的问题：新起的线程可能需要等待相当长的时间才会真正运行。这是一个相当无奈的结果，在多数情况下，我们都不能忍受等待这么长时间。以下的这段测试代码，在双核系统中，经过了大概5分钟的时间，才运行到了线程T201：
除了启动问题外，线程之间的切换也存在同样的问题，T201的下一次执行，还会等待相当长的时间。
所以，不要滥用线程，尤其不要滥用过多的线程。当新起线程的时候，需要仔细思考这项工作是否真的需要新起线程去完成。即使真的需要线程也应该考虑使用线程池技术。例如本建议所提到的Socket连接这样的I/O密集型场合，应当始终考虑使用异步来完成。异步会在后台使用线程池进行管理。1000台客户端在使用了异步技术后，实际只要几个线程就能完成所有的管理工作（具体取决于“心跳频率”）。
相关链接：
连载1 连载2 连载3 连载4 连载5 连载6 连载7 连载8 连载9
连载10 连载11 连载12 连载13 连载14 连载15 连载71 连载72 连载73
