使用Thread.Start与QueueUserWorkItem的优点

在多线程.NET编程中,使用ThreadPool.QueueUserWorkItem与通过新的Thread()和Thread.Start()启动自己的线程的决策标准是什么？

在服务器应用程序(比如说,ASP.NET应用程序或WCF服务)中,我认为ThreadPool始终存在且可用.在客户端应用程序中,如WinForms或WPF应用程序怎么样？启动线程池有成本吗？如果我只想让3或4个线程在一些计算上短时间工作,那么QUWI或Thread.Start()会更好吗？

ThreadPool始终存在,但是,根据处理器的数量,为池分配了有限数量的线程.对于ASP.NET应用程序,使用线程通常是一个坏主意,除非你真的开始使用Async进程并且知道不会有大量请求(请记住ThreadPool中有一定数量的线程)您与AppDomain中运行的所有内容共享,并且您希望使用新的Thread()创建的线程总数也存在实际限制.

对于WinForms应用程序,请考虑使用BackgroundWorker而不是使用Thread或ThreadPool.它使用ThreadPool,但是,它使多线程精明的程序员更容易在线程之间进行通信.

更新

避免使用ThreadPool.QueueUserWorkItem,因为您的应用程序池可能随时消失.如果必须,可以将此工作移到外面或使用WebBackgrounder.

来自Hanselman.com - "清单:ASP.NET中无法做什么"

我会把它作为评论,但它太长了.
CodemonkeyKing似乎已经发挥了重要作用,但在我看来并不够强烈.

您可以使用许多标准来描述代码.它会在长时间运行的应用程序中使用吗？Winforms app或不？它是服务器或客户端应用程序吗？库或独立的exe？等等

在我看来,如果您的代码将在一个独立的应用程序中运行,并且您可以控制所有周围的代码,那么您可以自己创建线程池,启动自己的线程,并测量和管理线程启动,线程延迟,和资源消耗.或者你可以使用QUWI,但它不会以任何方式杀死你的应用程序.你可以自由选择.

另一方面,如果您的代码打包为可以在服务器中使用的库 - 在ASP.NET中,或者在SQL CLR应用程序或WCF服务中 - 那么创建线程是一个非常糟糕的主意.您需要使用QUWI或其他一些利用内置线程池的机制(如BackgroundWorker).如果要在客户端应用程序中与其他库一起使用,则需要再次使用QUWI.想象一下,每个想要利用多核计算机的图书馆都会推出自己的线程.在使用多个库的应用程序中会出现完全混乱.猖獗的线程,都在竞争相同的资源.没有#threads vs#processor的中心协调.

好的hygeine 要求库,无论是在客户端应用程序还是服务器应用程序中使用,都使用公共线程池,这意味着QUWI.

最后要意识到的是这个;

托管线程是后台线程或前台线程.后台线程与前台线程相同,但有一个例外:后台线程不会使托管执行环境保持运行.一旦所有前台线程在托管进程中停止(其中.exe文件是托管程序集),系统将停止所有后台线程并关闭.

属于托管线程池的线程(即IsThreadPoolThread属性为true的线程)是后台线程.从非托管代码进入托管执行环境的所有线程都标记为后台线程.通过创建和启动新Thread对象生成的所有线程都是默认的前台线程.

如果使用线程来监视活动(例如套接字连接),请将其IsBackground属性设置为true,以便该线程不会阻止进程终止.

来自MSDN网站.