C# ThreadPool.QueueUserWorkItem 与 Task.Factory.StartNew
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9200573/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
ThreadPool.QueueUserWorkItem vs Task.Factory.StartNew
提问by stackoverflowuser
what is difference between the below
下面有什么区别
ThreadPool.QueueUserWorkItem
vs
对比
Task.Factory.StartNew
If the above code is called 500 times for some long running task does it mean all the thread pool threads will be taken up?
如果对于某个长时间运行的任务，上面的代码被调用 500 次，是否意味着所有的线程池线程都会被占用？
Or will TPL (2nd option) be smart enough to just take up threads less or equal to number of processors?
或者 TPL（第二个选项）是否足够聪明，只占用少于或等于处理器数量的线程？
采纳答案by Jon Skeet
If you're going to start a long-running task with TPL, you should specify TaskCreationOptions.LongRunning, which will mean it doesn'tschedule it on the thread-pool. (EDIT: As noted in comments, this isa scheduler-specific decision, and isn't a hard and fast guarantee, but I'd hope that any sensible production scheduler would avoid scheduling long-running tasks on a thread pool.)
如果您打算使用 TPL 启动一个长时间运行的任务，您应该指定TaskCreationOptions.LongRunning，这意味着它不会在线程池上安排它。（编辑：如评论中所述，这是特定于调度程序的决定，并不是硬性保证，但我希望任何明智的生产调度程序都会避免在线程池上调度长时间运行的任务。）
You definitely shouldn't schedule a large number of long-running tasks on the thread pool yourself. I believe that these days the default size of the thread pool is pretty large (because it's often abused in this way) but fundamentally it shouldn't be used like this.
您绝对不应该自己在线程池上安排大量长时间运行的任务。我相信现在线程池的默认大小非常大（因为它经常以这种方式被滥用）但从根本上说不应该这样使用。
The point of the thread pool is to avoid shorttasks taking a large hit from creating a new thread, compared with the time they're actually running. If the task will be running for a long time, the impact of creating a new thread will be relatively small anyway - and you don't want to end up potentially running out of thread pool threads. (It's less likely now, but I didexperience it on earlier versions of .NET.)
线程池的目的是避免短任务在创建新线程时受到较大影响，与它们实际运行的时间相比。如果任务将运行很长时间，无论如何创建新线程的影响将相对较小 - 您不希望最终可能用完线程池线程。（现在不太可能了，但我确实在 .NET 的早期版本上遇到过。）
Personally if I had the option, I'd definitely use TPL on the grounds that the TaskAPI is pretty nice - but doremember to tell TPL that you expect the task to run for a long time.
就我个人而言，如果我有选择，我肯定会使用 TPL，因为TaskAPI 非常好 - 但请记住告诉 TPL 您希望任务运行很长时间。
EDIT: As noted in comments, see also the PFX team's blog post on choosing between the TPL and the thread pool:
编辑：如评论中所述，另请参阅 PFX 团队关于在 TPL 和线程池之间进行选择的博客文章：
In conclusion, I'll reiterate what the CLR team's ThreadPool developer has already stated:
Task is now the preferred way to queue work to the thread pool.
最后，我将重申 CLR 团队的 ThreadPool 开发人员已经声明的内容：
Task is now the preferred way to queue work to the thread pool.
EDIT: Also from comments, don't forget that TPL allows you to use custom schedulers, if you really want to...
编辑：同样从评论中，不要忘记 TPL 允许您使用自定义调度程序，如果您真的想...
