编写高质量代码改善C#程序的157个建议——建议78：应避免线程数量过多

建议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：

static void Main(string[] args)
{
    for (int i = ; i < ; i++)
    {
        Thread t = new Thread(() =>
            {
                int j = ;
                while (true)
                {
                    j++;
                }
            });
        t.IsBackground = true;
        t.Start();
    }
    Thread.Sleep();
    Thread t201 = new Thread(() =>
        {
            while (true)
            {
                Console.WriteLine("T201正在执行");
            }
        });
    t201.Start();
    Console.ReadKey();
} 

除了启动问题外，线程之间的切换也存在同样的问题，T201的下一次执行，还会等待相当长的时间。

所以，不要滥用线程，尤其不要滥用过多的线程。当新起线程的时候，需要仔细思考这项工作是否真的需要新起线程去完成。即使真的需要线程也应该考虑使用线程池技术。例如本建议所提到的Socket连接这样的I/O密集型场合，应当始终考虑使用异步来完成。异步会在后台使用线程池进行管理。1000台客户端在使用了异步技术后，实际只要几个线程就能完成所有的管理工作（具体取决于“心跳频率”）。

转自：《编写高质量代码改善C#程序的157个建议》陆敏技