通常我不会发布带有答案的问题，但这次我想引起一些人对我认为可能是一个晦涩但普遍的问题的关注。它是由 this question 触发的，从那以后我检查了我自己的旧代码，发现其中一些也受此影响。

下面的代码启动并等待两个任务，task1 和task2，它们几乎相同。 task1 与 task2 的唯一区别在于它运行一个永无止境的循环。 IMO，这两种情况对于一些执行 CPU 密集型工作的现实场景来说都是非常典型的。

using System;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication
{
    public class Program
    {
        static async Task TestAsync()
        {
            var ct = new CancellationTokenSource(millisecondsDelay: 1000);
            var token = ct.Token;

            // start task1
            var task1 = Task.Run(() =>
            {
                for (var i = 0; ; i++)
                {
                    Thread.Sleep(i); // simulate work item #i
                    token.ThrowIfCancellationRequested();
                }
            });

            // start task2
            var task2 = Task.Run(() =>
            {
                for (var i = 0; i < 1000; i++)
                {
                    Thread.Sleep(i); // simulate work item #i
                    token.ThrowIfCancellationRequested();
                }
            });  

            // await task1
            try
            {
                await task1;
            }
            catch (Exception ex)
            {
                Console.WriteLine(new { task = "task1", ex.Message, task1.Status });
            }

            // await task2
            try
            {
                await task2;
            }
            catch (Exception ex)
            {
                Console.WriteLine(new { task = "task2", ex.Message, task2.Status });
            }
        }

        public static void Main(string[] args)
        {
            TestAsync().Wait();
            Console.WriteLine("Enter to exit...");
            Console.ReadLine();
        }
    }
}

fiddle is here .输出:

{ task = task1, Message = The operation was canceled., Status = Canceled }
{ task = task2, Message = The operation was canceled., Status = Faulted }

为什么task1的状态是Cancelled，而task2的状态是Faulted？ 请注意，在这两种情况下，我都不将 token 作为第二个参数传递给 Task.Run。

最佳答案

这里有两个问题。首先，传递 CancellationToken 总是一个好主意。到 Task.Run API，除了使其可用于任务的 lambda。这样做会将 token 与任务相关联，并且对于正确传播由 token.ThrowIfCancellationRequested 触发的取消至关重要。 .

但这并不能解释为什么 task1 的取消状态仍然可以正确传播( task1.Status == TaskStatus.Canceled )，但对于 task2 则不然(task2.Status == TaskStatus.Faulted)。

现在，这可能是非常罕见的情况之一，其中聪明的 C# 类型推断逻辑可以违背开发人员的意愿。讨论的很详细here和 here .综上所述，以防task1 , 以下覆盖 Task.Run由编译器推断:

public static Task Run(Func<Task> function)

而不是:

public static Task Run(Action action)

那是因为 task1 lambda 没有来自 for 的自然代码路径循环，所以它也可能是一个 Func<Task> lambda，尽管它不是 async而且它不返回任何内容。这是编译器比 Action 更喜欢的选项。 .然后，使用Task.Run这样的override等同于:

var task1 = Task.Factory.StartNew(new Func<Task>(() =>
{
    for (var i = 0; ; i++)
    {
        Thread.Sleep(i); // simulate work item #i
        token.ThrowIfCancellationRequested();
    }
})).Unwrap();

Task<Task> 类型的嵌套任务由 Task.Factory.StartNew 返回，得到 unwrapped至 Task通过 Unwrap() . Task.Run is smart enough当它接受 Func<Task> 时自动进行这样的解包. 展开的 promise 式任务正确地从其内部任务传播取消状态，作为 OperationCanceledException 抛出Func<Task> 异常 lambda 。 task2 不会发生这种情况, 它接受 Action lambda 并且不创建任何内部任务。 task2 的取消不会传播，因为 token尚未与 task2 相关联通过Task.Run .

最后，这可能是 task1 所希望的行为(当然不是 task2 )，但我们不想在任何一种情况下在幕后创建嵌套任务。此外，此行为适用于 task1通过引入条件 break 可能很容易被破坏来自 for循环。

task1 的正确代码应该是这样的:

var task1 = Task.Run(new Action(() =>
{
    for (var i = 0; ; i++)
    {
        Thread.Sleep(i); // simulate work item #i
        token.ThrowIfCancellationRequested();
    }
}), token);

关于c# - CancellationToken.ThrowIfCancellationRequested 后的故障与取消任务状态，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24359761/