线程vs ThreadPool

Question

使用新线程和使用线程池中的线程有什么区别？有什么性能优势，为什么我应该考虑使用池中的线程，而不是我显式创建的线程？我在这里特别提到了.NET，但是一般的例子也没问题。

Answer 1

线程池将通过以下方式为频繁和相对较短的操作提供好处

• 重用已经创建的线程，而不是创建新的线程(一个昂贵的process)
• Throttling当有大量的新工作项请求时(我相信这只在.NET 3.5中才有)
  • 如果您对100个线程池任务进行排队，它将只使用与已经创建的线程一样多的线程来服务于这些请求(例如，10个)。线程池将进行频繁的检查(我相信在3.5 SP1中每500ms检查一次)，如果有排队的任务，它将创建一个新线程。如果你的任务很快，那么新线程的数量就会很少，重用这10个左右的线程来完成短任务将比在front.

上创建100个线程更快

- If your workload consistently has large numbers of thread pool requests coming in, then the thread pool will tune itself to your workload by creating more threads in the pool by the above process so that there are a larger number of threads available to process requests

- check [Here](http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx) for more in depth info on how the thread pool functions under the hood

如果作业的运行时间相对较长(可能只有一两秒，但这取决于具体情况)，那么自己创建一个新线程会更合适。

@Krzysztof - Thread Pool线程是后台线程，将在主线程结束时停止。默认情况下，手动创建的线程是前台的(将在主线程结束后继续运行)，但可以在调用Start之前将其设置为后台。

Answer 2

.NET管理的线程池：-

• 根据当前工作负载以及可用的hardware
• Contains工作线程和完成端口线程(专门用于服务IO)调整自身的大小
• 针对大量相对较短的操作进行了优化

其他线程池实现可能更适合长时间运行的操作。

具体地说，使用线程池来防止您的应用程序创建太多线程。线程池最重要的特性是工作队列。也就是说，一旦您的机器足够繁忙，线程池将对请求进行排队，而不是立即产生更多的线程。

所以，如果你要创建一个有限数量的小线程，你可以自己创建它们。如果您不能预先确定可以创建多少线程(例如，它们是为响应传入的IO而创建的)，并且它们的工作将是短暂的，则使用线程池。如果您不知道有多少，但是他们的工作将是长期运行的，那么平台中没有任何东西可以帮助您-但是您也许能够找到适合的替代线程池实现。

Answer 3

也是

new Thread().Start()

派生前台线程，如果您关闭您的程序，它将不会终止。ThreadPool线程是关闭应用程序时死掉的后台线程。