C#并发编程:Task.Run vs Task.Factory.StartNew的生死抉择

如果你编写C#代码的时间足够长，你可能在实际代码中见过这两种API。有时它们甚至并排出现，通常没有任何注释解释为什么选择其中一个而不是另一个。乍一看它们似乎是可互换的。两者都创建任务，两者都异步运行工作，两者都能正常编译。

这种表面上的相似性正是为什么在Task.Run引入多年后，这个话题仍然不断引发问题的原因。问题不在于Task.Factory.StartNew已过时或有问题。问题在于它是一个低级API，大多数应用程序代码本不该触及它。然而它仍然被复制、粘贴，并像货物崇拜一样出现在那些默默改变执行语义的地方。

这篇文章主要面向资深开发者，但如果你职业生涯尚早，这仍然值得仔细阅读。这里讨论的错误很少出现在单元测试中。它们会在高负载下、关闭期间，或几个月后当有人向现有代码路径添加async时显现。

我将以直接和经验驱动的方式阐述。如果你在应用程序代码中使用Task.Factory.StartNew，你应该有非常具体的理由。如果你无法清晰阐述那个理由，你几乎肯定用错了API。

让我恍然大悟的生产故障

几年前，我接手了一个偶尔在关闭时挂起的服务。不总是，甚至不经常。可能每几周一次。日志看起来很干净。没有明显的死锁。没有线程池饥饿警告。就是一个拒绝退出的进程。

经过数天的跟踪，罪魁祸首最终被确定为一个深埋在辅助方法中的单行代码：一个包裹async委托的Task.Factory.StartNew。外部任务立即完成，实际工作在稍后运行，而关闭逻辑等待的是从未被真正跟踪的东西。没有什么"错误"到会崩溃，只是"错误"到在进程生命周期后仍然泄露工作。

那次经历永久改变了我看待这些API的方式。这段代码是由一个称职的开发者编写的。它通过了审查。它在测试中工作。然而它编码了关于调度和任务生命周期的假设，这些假设根本就是不真实的。

这就是本文要讨论的那种失败。

StartNew存在的真正原因

Task.Factory.StartNew是先出现的。它被设计为一个通用的任务构造API，暴露了任务并行库提供的几乎每个可调节参数。调度器选择、任务创建选项、子任务附加、长时间运行提示等等。

这种灵活性是有意为之的StartNew是为框架级代码构建的。这些代码需要与自定义调度器协作。代码在任务之上构建更高级别的抽象。由那些完全理解任务调度工作原理的人编写的代码。

然后，真实世界的应用程序开发者开始使用它。

结果是可预测的。任务在不期望的线程上运行。任务无意中继承同步上下文。子任务以令人惊讶的方式附加自身。异常消失或在完全不同的时间出现。

后来引入Task.Run作为纠正措施。它不是一个便利包装器。它是一个有主见的API，故意隐藏危险的选择并强制使用合理的默认值。它总是使用线程池调度器。它总是正确解包async委托。它从不隐式附加子任务。

换句话说，Task.Run之所以存在，是因为StartNew太容易被误用。

仍在生产中出现的经典异步陷阱

让我们从一段看起来无害且仍在代码审查中出现的代码开始：

Task.Factory.StartNew(async () =>
{
await DoWorkAsync();
});

如果你曾经写过这样的代码，你并不孤单。它能编译。它能运行。没有立即爆炸。这正是它危险的原因。

你在这里实际创建的是一个Task<Task>。StartNew对async委托没有特殊的理解。它看到一个返回Task的函数，并将返回的任务视为另一个对象。外部任务在委托达到第一个await时立即完成。

现在在DoWorkAsync内部抛出的异常与你认为你启动的任务分离了。取消行为变得奇怪。等待外部任务不会像你期望的那样工作，因为实际工作位于更深一层。

现在与正确版本比较：

Task.Run(async () =>
{
await DoWorkAsync();
});

Task.Run自动解包内部任务。异常正确流动。等待按预期工作。取消行为可预测。

仅凭这一点就足以让Task.Run成为默认选择。但这只是开始。

TaskScheduler.Current

这些API之间最重要的技术区别是它们默认使用的调度器。

Task.Factory.StartNew使用TaskScheduler.Current。

Task.Run总是使用TaskScheduler.Default。

这种区别听起来很学术，直到你意识到TaskScheduler.Current的实际含义。它不是"线程池"。它是"当前此线程上恰好处于活动状态的任何调度器"。

在控制台应用程序中，这两者通常相同。在实际应用程序中，它们经常不同。

当你在具有自定义调度器的上下文中调用StartNew时，你的任务会自动继承该调度器。这包括UI环境、请求处理管道、测试运行器以及任何安装了自己调度行为的框架。

这就是开发者如何意外地将CPU密集型工作排队到UI调度器上的原因。或者在ASP.NET请求上下文中运行阻塞工作。或者在没有意识到的情况下序列化执行。

Task.Run避开了所有这些。它总是将工作调度到默认线程池。没有上下文继承。没有意外。不会意外耦合到调用者的执行环境。

这一个设计决策消除了整整一类难以重现的错误。

子任务和意外耦合

另一个几乎没有人考虑的差异是子任务附加。

StartNew暴露TaskCreationOptions，包括允许子任务隐式附加到父任务的选项。这改变了完成语义。父任务可能直到所有附加的子任务完成后才完成，即使这些子任务是在另一个方法深处创建的。

这种行为在构建结构化并发原语时偶尔有用。在应用程序代码中几乎从来不可取。

Task.Run不暴露这种能力。在Task.Run委托内部创建的子任务默认是分离的。完成意味着你认为它意味着的含义。

再次强调，这不是一个限制。这是一个故意的防护栏。

异常传播和可观察性

当任务被正确调度和正确解包时，异常行为是直接的。当它们不是时，事情很快就会变得奇怪。

使用StartNew，特别是与async委托或自定义调度器结合时，异常可能在意想不到的地方出现。有时只有在终结器线程运行时才会观察到它们。有时它们会被吞没，直到TaskScheduler.UnobservedTaskException触发，假设有人正在监听。

这就是团队最终得到的日志显示"任务出错"但没有明显负责的调用站点的原因。

Task.Run保持异常生命周期与你实际创建的任务相关联。当你等待它时，你看到异常。当你没有等待时，故障仍然与行为一致的具体工作单元相关联。

LongRunning和优化神话

偶尔有人为StartNew辩护的一个论点是能够指定TaskCreationOptions.LongRunning。暗示是这会给你性能控制。

实际上，这几乎总是被误用。

LongRunning是一个提示，告诉调度器考虑创建专用线程而不是使用线程池。这是一个有显著权衡的沉重决定。它绕过了线程池启发式算法，很容易降低整体系统吞吐量。

如果你真的需要那种级别的控制，你已经处于StartNew有意义的空间。如果你不完全确定你需要它，那么你就不需要。

那么StartNew何时真正正确？

Task.Factory.StartNew确实有合法的用途。

如果你正在编写与自定义调度器集成的框架代码。如果你正在构建更高级别的并发原语。如果你需要对任务创建语义进行精确控制并完全理解其后果。

换句话说，如果你不得不问StartNew是否合适，那么它可能不合适。

对于应用程序代码、后台工作、即发即弃操作或任何涉及async方法的场景，Task.Run是正确的默认选择。不是因为它更简单，而是因为它编码了正确的假设。

经验法则

以下是有主见的结论。

如果你在线程池上运行工作，使用Task.Run。

如果你处理异步代码，使用Task.Run。

如果你不需要明确考虑调度器、子任务附加或创建选项，使用Task.Run。

只有当你能用具体术语解释为什么Task.Run的默认值对你的场景错误时，才使用Task.Factory.StartNew。

大多数关于任务的生产错误不是由缺少功能引起的。它们是由使用假设调用者拥有比实际更多知识的API引起的。

Task.Run的存在就是为你编码那些知识。让它发挥作用。

这个比较不断重新出现的原因不是因为API不清晰。而是因为其中一个看起来欺骗性地熟悉，却在抽象层次低得多的层面上运行。

Task.Factory.StartNew假设你理解调度器、任务生命周期、附加语义和异常观察。它假设你是有意选择进入这种复杂性。在应用程序代码中，这种假设几乎总是错误的。

Task.Run不是一个快捷方式。它是一个约束。它故意移除了大多数开发者根本不应该做出的选择。这就是为什么它在不同环境中行为可预测，在重构中存活，并以你可以实际诊断的方式失败。

注，如有侵权，请第一时间联系删除，谢谢。