C# 非 async 函数调用 async 函数的正确姿势：从死锁规避到性能优化

1次阅读

没有评论

共计 1776 个字符，预计需要花费 5 分钟才能阅读完成。

在 C# 开发中，我们经常会遇到需要从同步方法调用异步代码的情况。这种场景看似简单，实则暗藏玄机。今天，我们就来深入探讨这个问题，分享一些实用的解决方案和优化技巧。

当我们在同步方法中直接调用 async 方法并使用 .Result 或 .Wait() 时，很可能会遇到死锁问题。这是因为 SynchronizationContext 在作祟。

SynchronizationContext 的作用是确保代码在正确的上下文中执行（如 UI 线程）
当异步操作完成后，它会尝试回到原始上下文继续执行
如果原始上下文已经被同步调用阻塞，就会形成死锁

常见的错误模式包括：

直接使用 Task.Result 或 Task.Wait()
没有考虑线程池资源，导致线程池饥饿
在 UI 线程中阻塞异步调用

这个方案可以避免上下文切换，但不适合所有场景：

适用于不需要回到原始上下文的场合
不适用于需要操作 UI 元素的代码
不能完全解决所有死锁问题

这是一个常用但需要谨慎使用的方案：

会将工作推送到线程池
有额外的线程切换开销
适合 CPU 密集型操作

两者在异常处理上有明显区别：

.Result 会将异常包装在 AggregateException 中
.GetAwaiter().GetResult() 会直接抛出原始异常
后者通常更便于调试

下面是一个可复用的 AsyncHelper 工具类：

/// <summary>
/// 提供同步调用异步方法的工具
/// </summary>
public static class AsyncHelper
{
    private static readonly TaskFactory _taskFactory = new 
        TaskFactory(CancellationToken.None, 
                    TaskCreationOptions.None, 
                    TaskContinuationOptions.None, 
                    TaskScheduler.Default);

    /// <summary>
    /// 同步执行异步方法
    /// </summary>
    public static TResult RunSync<TResult>(Func<Task<TResult>> func)
    {
        return _taskFactory
            .StartNew(func)
            .Unwrap()
            .GetAwaiter()
            .GetResult();}

    /// <summary>
    /// 带超时控制的同步执行
    /// </summary>
    public static TResult RunSync<TResult>(Func<Task<TResult>> func, TimeSpan timeout)
    {
        try
        {
            return _taskFactory
                .StartNew(func)
                .Unwrap()
                .Wait(timeout)
                ? func.GetAwaiter().GetResult()
                : throw new TimeoutException();}
        catch (AggregateException ex)
        {throw ex.InnerException ?? ex;}
    }
}

使用 BenchmarkDotNet 测试不同方案的性能表现：