[译]FAQ on Task.Start

最新推荐文章于 2024-11-17 21:25:27 发布

weixin_30511107

最新推荐文章于 2024-11-17 21:25:27 发布

阅读量55

点赞数

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/jiaxingseng/archive/2012/02/04/2338070.html

本文详细解答了关于Task.Start方法的常见疑问，包括何时使用、如何使用及注意事项等内容，并对比了Task.Factory.StartNew方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Task的API设计确实有很多令人迷惑的地方，所以真的非常感谢Stephen Toub的这篇FAQ。节译其中的主要部分。

1.Q：我应该什么时候使用Task.Start？

A：Start实例方法可以用在且只能用在task处在Created状态（也就是task.Status返回TaskStatus.Created），而唯一能使task处在这一状态的方式就是使用Task的public构造器

2.Q：我有一个由Task.Run / Task.ContinueWith / Task.Factory.StartNew / TaskCompletionSource / 异步方法创建的task，我能不能对其调用Start方法？

A：如上所述，不能。会抛异常的。以上任意一个方法创建的task都意味着task不再处在Created状态，而是其他状态例如TaskStatus.WaitingForActivation、TaskStatus.Running、TaskStatus.RanToCompletion

3.Q：Start方法实际上做了什么？

A：它把task放入目标TaskScheduler（无参的Start方法意味着目标TaskScheduler为TaskScheduler.Current）。当你使用构造器创建一个task，它处于非活动状态，也就是说没有被放入任何一个TaskScheduler，因而没人会运行它。如果你不调用Start方法，它永远不会被放入队列，所以永远不会完成。想让task被执行，就需要把它放入队列，这样调度器会在它认为合适的时机运行你的task。Start方法会对task对象做一些变化（例如修改状态为WaitingToRun），之后调用目标TaskScheduler的QueueTask方法将其放入队列，从此时开始，task未来的运行就交由调度器处理，调度器最终会调用TryExecuteTask方法执行你的task。

4.Q：我能对同一个task多次调用Start方法么？

A：不能。一个task从Created状态变到别的状态这个行为只能出现一次，Start方法就会导致这个行为，所以Start方法也只能被调用一次。多次调用只会导致异常。Start方法引入了同步机制来保证task对象处在一致性的状态，所以即使多次并发的调用Start方法，也只有其中的一次调用会成功。

5.Q：Task.Start和Task.Factory.StartNew有什么不同？

A：Task.Factory.StartNew是一种简略的写法，实际就是构造一个task然后Start，所以如下的代码

var t = Task.Factory.StartNew(someDelegate);

和如下的代码从效果上是相同的

var t = new Task(someDelegate);
t.Start();

但从性能上来说，前者更好。如#3中所说，Start方法引入了同步机制来保证该task在Start之前尚未Start，也不会被并发的多次Start。与之相对的，StartNew方法知道不可能有其他人Start这个task因为这个引用尚未返回给任何人，所以StartNew方法无需引入同步机制。

6.Q：我听说调用Task.Result也可以开始一个task？

A：没这回事。当一个task处在Created状态，只有两种可能性使其变化到其他状态。

1. 构造task时传入了一个CancellationToken，当task还在Created状态时有了取消请求，那么task会变化为Canceled状态。

2. 有人调用了Start方法

调用Result不属于上述两种之一。当你对一个还处在Created状态的task调用Wait方法或者Result，调用会被阻塞。直至有人调用了Start，之后balabala，最终task完成了，被阻塞的调用才会完成。

你以为调用Result可能会开始一个task，那是不对的。实际上那倒有可能导致task被“内联”的执行。当task已经被放入TaskScheduler的队列，它也许并未开始，依然躺在队列里，当你对这种task调用Result，运行时可能会尝试内联的执行这个task（也就是说在你的调用线程上执行task），而不会等某个其他线程啥时候闲下来有空。从内部来说，就是Result内部也许会调用TaskScheduler的TryExecuteTaskInline方法，当然以上所说的“也许”都取决于TaskScheduler想怎么执行你的请求。

7. Q：我设计了一个公开的API要返回一个task，我应该返回一个尚未开始的task么？

A：不要这么做。（这里把这个问题和#1、#2区别对待是因为#1和#2是真的想创建一个task之后可能选择不开始它。大家不要以为非得违背设计意图的开始一个不想开始的task之后返回）

那么，通常的来讲如果你调用的是一个同步方法，那个方法肯定是你一调用就开始执行的。那么在返回一个task对象的异步方法的场合，你可以认为task就是未来终将会完成的异步方法，那并不改变一个事实：通过这个方法的调用，相应的操作应该已经开始执行了。因此，如果你返回一个尚未开始的task从语义上来讲就很奇怪。

所以如果你在方法内部使用构造器创造了一个task，那么在返回它之前记得调用Start，否则可能引起死锁或者类似的情况，因为消费者会期待着你返回的task终将完成，但如果你根本没开始这个task那它当然也就无从完成。有些框架甚至允许你通过一个方法或者委托神马的来指定一个检查，当你启用了这个检查，框架会检查返回的task的状态，如果尚处在Created状态会抛异常。

8. Q：说了半天我到底应不应该首先调用构造器创造一个task然后调Start呢？

A：对于大多数场合，你蛮好还是直接调用Task.Run或者TaskScheduler.StartNew吧，如果你的需求仅仅是让调度器帮你异步执行一段委托。这样不仅代码少，性能也好（如#5所述），而且减少了出错的几率（比如你忘了调Start神马的）。

当然构造器+Start方法也有其用武之地。比如你派生了自己的Task类型，那你就需要Start方法来真正把你的对象放入队列。再来看一个高级点例子：如果你想要在task的委托里使用这个task对象

Task theTask = null;
theTask = Task.Run(() => Console.WriteLine(“My ID is {0}.”, theTask.Id));

发现破绽了么？这儿有个竞态。当你调用Task.Run时，一个新的task对象被创建出来并被放入TaskScheduler的队列，如果当时线程池很闲，也许立刻就会有个线程来执行这段委托，这个线程会访问由主线程创建的theTask对象，从而存在一个竞态。想避免这种情况，只要把构造和开始分开执行就好了

Task theTask = null;
theTask = new Task(() =>Console.WriteLine(“My ID is {0}.”, theTask.Id));
theTask.Start(TaskScheduler.Default);

现在就可以保证在委托线程访问theTask对象之前主线程已经完成了对它的赋值

转载于:https://www.cnblogs.com/jiaxingseng/archive/2012/02/04/2338070.html