不在 TPL Task 对象上调用 Dispose() 是否可以接受？

Question

我想触发一个任务在后台线程上运行。我不想等待任务完成。

在 .net 3.5 中我会这样做：

ThreadPool.QueueUserWorkItem(d => { DoSomething(); });

在 .net 4 中，建议使用 TPL。我见过推荐的常见模式是：

Task.Factory.StartNew(() => { DoSomething(); });

但是，StartNew() 方法返回一个实现IDisposable 的Task 对象。这 似乎被推荐这种模式的人忽略了。 Task.Dispose() 方法的 MSDN 文档说：

“在释放对任务的最后引用之前，始终调用 Dispose。”

在任务完成之前，您不能对任务调用 dispose，因此让主线程等待并调用 dispose 会首先破坏在后台线程上执行的点。似乎也没有任何已完成/已完成的事件可用于清理。

Task 类的 MSDN 页面对此没有评论，《Pro C#2010...》一书推荐了相同的模式，对任务处置不做评论。

我知道如果我离开它，终结器最终会捕获它，但是当我执行大量这样的 fire & forget 任务并且终结器线程不堪重负时，这会回来咬我吗？

所以我的问题是：

• 在这种情况下不调用Dispose() 在Task 类上是否可以接受？如果是这样，为什么以及是否存在风险/后果？
• 是否有任何文档对此进行了讨论？
• 或者是否有适当的方法来处理我错过的Task 对象？
• 或者是否有其他方法可以使用 TPL 执行“即发即弃”任务？

Answer 1

有一个关于这个in the MSDN forums的讨论。

Microsoft pfx 团队的成员 Stephen Toub 这么说：

Task.Dispose 因 Task 而存在 可能包装事件句柄 等待任务时使用 完成，如果等待 线程实际上必须阻塞（如 反对旋转或可能 执行它正在等待的任务）。 如果你所做的只是使用 延续，该事件句柄将 永远不会被分配
...
依靠最终确定来处理事情可能会更好。

更新（2012 年 10 月）
Stephen Toub 发布了一篇名为 Do I need to dispose of Tasks? 的博客，其中提供了更多详细信息，并解释了 .Net 4.5 中的改进。

总而言之：您不需要在 99% 的时间处理 Task 对象。

释放对象有两个主要原因：及时、确定地释放非托管资源，以及避免运行对象的终结器的成本。大多数情况下，这些都不适用于Task：

1. 从 .Net 4.5 开始，Task 分配内部等待句柄（Task 对象中唯一的非托管资源）的唯一时间是当您显式使用 Task 的 IAsyncResult.AsyncWaitHandle 时，并且
2. Task 对象本身没有终结器；句柄本身被包装在一个带有终结器的对象中，因此除非它被分配，否则没有终结器可以运行。

Answer 2

这与 Thread 类的问题相同。它消耗 5 个操作系统句柄，但不实现 IDisposable。原设计者的好决定，当然很少有合理的方法来调用 Dispose() 方法。你必须先调用 Join()。

Task 类为此添加了一个句柄，即内部手动重置事件。哪个是最便宜的操作系统资源。当然，它的 Dispose() 方法只能释放那一个事件句柄，而不是 Thread 消耗的 5 个句柄。 Yeah, don't bother.

请注意，您应该对任务的 IsFaulted 属性感兴趣。这是一个相当丑陋的话题，您可以在MSDN Library article 中阅读更多相关信息。一旦你正确处理了这个问题，你的代码中也应该有一个很好的位置来处理任务。

Answer 3

我很乐意看到有人对这篇文章中展示的技术进行权衡：Typesafe fire-and-forget asynchronous delegate invocation in C#

看起来像一个简单的扩展方法将处理与任务交互的所有琐碎情况，并能够对其调用 dispose。

public static void FireAndForget<T>(this Action<T> act,T arg1)
{
    var tsk = Task.Factory.StartNew( ()=> act(arg1),
                                     TaskCreationOptions.LongRunning);
    tsk.ContinueWith(cnt => cnt.Dispose());
}