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

【问题标题】：How important is it to specify LongRunning on a Task?在任务上指定 LongRunning 有多重要？
【发布时间】：2020-05-25 13:29:39
【问题描述】：

How to pass LongRunning flag specifically to Task.Run()? 强调将任务创建标志放入较新的 API 中可能会有点混乱，尤其是使用 async 模式。

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

我的理解是，这个标志实际上会导致 TPL 启动一个专用线程而不是强调线程池，但特别是如果我的应用程序不涉及大量并行任务，这真的很重要吗？如果我的预期并行度小于默认线程池大小（无论是什么），我可以安全地忽略该标志吗？线程池可能会在几百毫秒内缺少线程吗？

【问题讨论】：

如果您忽略它，它不会完全中断，但如果您确实使线程池饱和，则可能需要更长的时间才能启动额外的线程来处理新任务。您是否有不想传递此值的原因？总是当我看到人们问“我想避免做 X，它安全吗？”我的直接问题总是“你为什么要避免做 X？”。
in practice will cause TPL to spin up a dedicated thread - this answer 从您的链接中解释说不会。也可能看到 blog.stephencleary.com/2013/08/startnew-is-dangerous.html 在第 3 项中讨论 LongRunning。
@GSerg 您引用的链接与 OP 声称目前 TPL 通过启动专用线程来尊重 LongRunning 标志的说法并不矛盾。只是不能保证这种行为会永远保持不变。有朝一日微软会修改已有十年历史的 API 行为的可能性是任何人的猜测。我的猜测是：概率很低。
当您问“我可以安全地忽略该标志”时，您的意思是“我可以安全地忽略该标志”吗？
@TheodorZoulias 确实，已更正

标签： c# task-parallel-library

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

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

你是对的，LongRunning 标志很可能会导致创建新线程......当新任务需要更长的时间并且线程创建时间并不重要时，这很有意义。

线程池有一定的算法，如果你从那里密集地占用大量线程并保持它们忙碌，它可能会决定将线程数量加倍假设您要占用越来越多的资源……因此，如果您要让线程池中的线程忙碌足够长的时间，您将不会从线程池中获得任何好处，而是会产生一些开销。

所以忽略该标志不会破坏任何东西，但可能会带来一些开销。

【讨论】：

在我们不使用大量线程或性能的小型应用程序中，哪种类型的推论根本不是问题，它是安全的 - 但也许应该这样评论/记录。或者我们只是以“正确”的方式来做。