调用异步方法与Task.Run包裹调用的差异及应用影响

示例代码 #

[Test]
public async Task method1()
{ 
    Task task = run();
    await Task.WhenAll(task);
}

[Test]
public async Task method2()
{
    Task task = Task.Run(async() =>
    {
        await run();
    });
    await Task.WhenAll(task);
}

public async Task run()
{
    Console.WriteLine("Current Thread Name: " + Thread.CurrentThread.Name);
    // background thread to print numbers with sleep of 1s
    await Task.Run(() =>
    {
        for (int i = 1; i <= 2; i++)
        {
            Console.Write(i + " ");
            Thread.Sleep(1000);
        }
        Console.WriteLine();
    });
}

输出差异 #

• method1输出：

  Current Thread Name: NonParallelWorker
  1 2
  

• method2输出：

  Current Thread Name: .NET TP Worker
  1 2
  

核心差异解析 #

• 同步代码段的执行线程：
  method1直接调用run()，run()中await之前的同步代码（打印线程名的逻辑）会在调用线程（测试框架的NonParallelWorker线程）上执行；method2用Task.Run包裹run()调用，会把run()的启动逻辑调度到.NET线程池（.NET TP Worker）的线程上执行，因此同步代码段跑在线程池线程。
• 执行上下文的传递：
  直接调用run()会继承当前调用线程的执行上下文（比如同步上下文、线程本地存储）；Task.Run默认会脱离当前上下文执行，不会携带原线程的上下文信息。
• 调度开销：
  method2多了一层Task.Run的调度，会额外触发一次线程池线程的分配与调度操作，相比method1存在微小的性能开销，高频调用场景下可能累积。

对应用的影响 #

• 上下文依赖场景：如果run()的同步代码段需要依赖调用线程的上下文（比如UI线程的控件访问、特定线程本地变量），method1能保留上下文，method2则会丢失上下文，可能引发错误。
• UI线程阻塞风险：如果调用线程是UI线程，method1中run()的同步代码会在UI线程执行，若同步代码耗时较长会阻塞UI；method2通过Task.Run把同步代码放到线程池，能避免UI阻塞。
• 测试与生产环境一致性：测试框架的NonParallelWorker线程有特定调度规则，method2用线程池线程执行，更贴近生产环境中后台任务的运行方式，测试结果更具参考性。

内容的提问来源于stack exchange，提问作者ankushbbbr