在任务上指定 LongRunning 有多重要？

Question

如何将 LongRunning 标志专门传递给 Task.Run()？ 强调将任务创建标志放入较新的 API 可能有点麻烦，尤其是使用async模式。

我发现这篇文章声称async不是一个好主意，不应该使用： http : //blog.i3arnon.com/2015/07/02/task-run-long-running/

我的理解是，这个标志在实践中会导致 TPL 启动一个专用线程而不是给线程池带来压力，但特别是如果我的应用程序不涉及大量并行任务，这真的很重要吗？ 如果我的预期并行度小于默认线程池大小（无论是什么），我是否可以安全地省略该标志 - 最糟糕的情况是线程池可能会在几百毫秒内缺乏线程？

Answer 1

在不传递TaskCreationOptions参数的情况下调用Task.Factory.StartNew方法时，默认情况下会省略LongRunning标志，因此您可以放心地假设省略它是安全的。 实际上省略它比包含它更安全，因为这个标志旨在作为一种性能优化技术，而不是作为日常用品。

一般来说，除非你发现你真的需要它，否则不要使用它。 如果您通过性能测试发现不使用LongRunning会导致其他工作的处理长时间延迟，则通常只使用LongRunning 。 （引文）

如果ThreadPool因为它的线程被滥用（在等待 I/O 操作完成时被阻塞）而经常被饿死，那么与其用LongRunning标志装饰你的所有Task ，一个更简单、更有效的解决方法可能是在应用程序初始化期间，使用方法ThreadPool.SetMinThreads增加ThreadPool线程的最小数量。 例如：

ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 5);

当您重构应用程序以正确使用异步时，撤消此 hack 会更容易，而不是撤消代码中随处可见的LongRunning标志。

Answer 2

线程池背后的整个想法是创建任务需要几毫秒，因为它要求操作系统创建它，切换上下文等等......所以要处理它，框架创建一些池，并将使用的线程保留在那里以后用...

你是对的，LongRunning 标志很可能会导致新线程创建......当新任务将花费更长的时间并且线程创建时间在其中并不重要时，这是有道理的。

线程池有一定的算法，如果你从那里密集地获取大量线程并让它们忙碌，它可能会决定将线程数量加倍，假设你将占用越来越多......所以如果你要从线程池忙得够久了，你不会从线程池中得到任何好处，反而会得到一些开销。

因此，忽略该标志不会破坏任何内容，但可能会带来一些开销。