C# async-over-sync 反模式 + HttpClient 端口耗尽两连击雪崩复盘:从 P99 11s 到 115ms 的全过程

我们的一个 ASP.NET Core 后端服务上线第二天就开始卡死,Kestrel 进程的 CPU 占用是 0%,内存稳定不涨,但所有请求全部挂在那里超时,看起来像是死锁。这种"什么征兆都没有"的死锁是 C# 异步编程最经典的坑——同步代码里调用了 async 方法的 .Result 或 .Wait(),触发了同步上下文死锁。我们花了一整夜排查,最后用 WinDbg 抓 dump 才看清楚是什么把线程卡住了。这篇把这次事故的完整复盘写一遍,顺便讲清楚 ConfigureAwait(false)、SynchronizationContext、TaskScheduler 这几个 C# 开发者经常搞不明白的概念,以及一份"async/await 防呆守则"。

事故现场

背景是一个 ASP.NET Core 7.0 后端服务,提供企业内部的数据查询 API,日 QPS 大约两千,数据源是 SQL Server 加 Redis 缓存。上线第二天用户反馈"接口巨慢甚至超时",查 APM 看 P99 飙到 30 秒(超时上限),P50 也涨到 8 秒。运维同学先重启了一下进程,接口恢复正常,但几分钟后又开始卡死,典型的"重启可以续命但治不了病"的死锁现象。

引发死锁的那段代码

抓到 dump 之后,问题代码非常清晰。是一个上线前临时塞进去的"缓存预热"逻辑,作者怕 async 方法在构造函数里没法用,直接 .Result 同步等待。在控制台或单元测试里这种写法没问题,但在 ASP.NET Core 的请求处理链路里,如果存在 SynchronizationContext,这种写法就会死锁。

// 反面教材: 死锁的根源
public class DataController : ControllerBase
{
    private readonly IDataService _service;

    public DataController(IDataService service)
    {
        _service = service;
        // 灾难性写法: 在构造函数里同步等待 async 方法
        var warmup = _service.WarmupCacheAsync().Result;  // ← 这里会死锁
    }

    [HttpGet("query")]
    public async Task Query(string key)
    {
        var data = await _service.GetAsync(key);
        return Ok(data);
    }
}

public class DataService : IDataService
{
    public async Task WarmupCacheAsync()
    {
        await Task.Delay(100);  // 模拟异步调用
        // 默认 ConfigureAwait(true), 试图回到原线程
        return true;
    }
}

为什么 .Result 会死锁?核心原因是 SynchronizationContext。在 ASP.NET Core 早期版本(.NET Framework 时代)里,ASP.NET 自带一个 AspNetSynchronizationContext,要求 await 之后的延续(continuation)必须回到原线程执行。如果原线程正在被 .Result 同步阻塞等待这个 Task 完成,而 Task 又在等原线程被释放,就形成了完美的死锁:线程在等 Task,Task 在等线程。

同步上下文的工作原理

SynchronizationContext 是 .NET 用来"切换执行上下文"的机制。WinForms、WPF、ASP.NET Framework 都有自己的 SynchronizationContext,目的是确保 UI 更新或请求处理在正确的线程上执行。await 关键字默认会捕获当前 SynchronizationContext,在 Task 完成后通过 Post 方法把延续派发回原上下文。这种机制在大多数情况下是合理的,但在同步阻塞时就成了死锁的温床。

这里特别值得说明的是,ASP.NET Core(不是 Framework)默认没有 SynchronizationContext,理论上不会有这种死锁。但很多老代码在迁移过程中会带入 SynchronizationContext 的依赖,或者中间件层里被开发者人为加了一个,就触发了这个经典坑。我们的事故是因为用了一个老的第三方库,内部启动时 set 了一个自定义 context,影响了整个进程。

修复方案一:全程 async/await

最根本的修复是禁止任何形式的同步阻塞。.Result、.Wait()、GetAwaiter().GetResult() 这些都不能用,任何 async 方法的调用都必须 await。如果实在需要在构造函数里做异步初始化,改成工厂方法,先 await 异步初始化再 new 出对象。

// 修复后: 用工厂方法替代构造函数里的同步等待
public class DataController : ControllerBase
{
    private readonly IDataService _service;

    public DataController(IDataService service)
    {
        _service = service;
        // 构造函数里什么都不做, 异步初始化交给 DI 框架或 hosted service
    }

    [HttpGet("query")]
    public async Task Query(string key)
    {
        var data = await _service.GetAsync(key);
        return Ok(data);
    }
}

// 缓存预热改成 IHostedService, 在应用启动时执行
public class CacheWarmupService : IHostedService
{
    private readonly IDataService _service;

    public CacheWarmupService(IDataService service) => _service = service;

    public async Task StartAsync(CancellationToken cancellationToken)
    {
        await _service.WarmupCacheAsync();
    }

    public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
}

// Program.cs 里注册
builder.Services.AddHostedService();

IHostedService 是 ASP.NET Core 提供的后台任务接口,StartAsync 在应用启动时被调用,可以安全地 await。这种模式既满足了"启动时预热缓存"的需求,又彻底避免了构造函数里的同步等待陷阱。所有"需要异步执行的启动任务"都应该用 IHostedService,这是 ASP.NET Core 的标准做法。

修复方案二:ConfigureAwait(false)

第二个修复是给所有库代码加 ConfigureAwait(false)。这个方法告诉 await:不需要捕获 SynchronizationContext,延续可以在任意线程上执行。库代码(不是应用代码)应该全程用 ConfigureAwait(false),因为库不知道调用方有没有 SynchronizationContext,加上更安全也更高效。

// 库代码: 全程 ConfigureAwait(false)
public class DataService : IDataService
{
    private readonly HttpClient _http;
    private readonly IDistributedCache _cache;

    public async Task GetAsync(string key)
    {
        // 先查缓存
        var cached = await _cache.GetAsync(key).ConfigureAwait(false);
        if (cached != null)
            return Deserialize(cached);

        // 缓存未命中, 调上游
        var resp = await _http.GetAsync($"/data/{key}").ConfigureAwait(false);
        resp.EnsureSuccessStatusCode();
        var json = await resp.Content.ReadAsStringAsync().ConfigureAwait(false);
        var data = JsonSerializer.Deserialize(json);

        // 异步写回缓存
        await _cache.SetAsync(key, Serialize(data),
            new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5) })
            .ConfigureAwait(false);

        return data;
    }

    public async Task WarmupCacheAsync()
    {
        await Task.Delay(100).ConfigureAwait(false);
        return true;
    }
}

ConfigureAwait(false) 的好处是性能略好(不需要切换上下文)和避免死锁(不依赖原线程)。代价是延续可能在其他线程上执行,代码里不能访问线程局部状态(比如 ASP.NET Framework 的 HttpContext.Current)。在 ASP.NET Core 里 HttpContext 不再依赖线程局部存储,所以这个代价基本不存在,库代码加 ConfigureAwait(false) 是几乎无成本的优化。

修复方案三:用 analyzer 强制检查

事故之后我们在 CI 里加了 Roslyn analyzer,强制检查 .Result、.Wait()、GetAwaiter().GetResult() 等危险写法,任何出现都让 build 失败。这种强制检查比"靠 code review 把关"靠谱得多,人是会疲劳的、会遗漏的,机器不会。Microsoft 官方就提供了一些相关 analyzer(比如 AsyncFixer、Microsoft.VisualStudio.Threading.Analyzers),开箱即用。

  
    net7.0
    true
    enable
  

  
    
    
    
  

这几个 analyzer 各有侧重。Microsoft.VisualStudio.Threading.Analyzers 检查同步/异步混用、ConfigureAwait 缺失等。AsyncFixer 关注更多 async/await 反模式,比如 async void、未 await 的 Task 等。Meziantou.Analyzer 是社区出名的全面检查,覆盖很多 C# 编码规范。三个一起用,几乎能覆盖所有常见的 async 陷阱,新提交的代码如果踩坑直接 build 不过,防患于未然。

常见的 async/await 反模式

除了死锁,async/await 还有几个常见的反模式值得专门讲。第一个是async void。除了事件处理器,任何方法都不应该返回 async void,因为这种方法抛出的异常无法被 try/catch 捕获,只会触发进程级的 UnhandledException,直接搞挂应用。正确做法是返回 async Task。

// 反面: async void 的危险
public async void DoSomething()  // ❌ 异常吃不到, 进程挂掉
{
    throw new Exception("oops");
}

// 正面: async Task
public async Task DoSomethingAsync()  // ✅ 异常可以 await 时捕获
{
    throw new Exception("oops");
}

// 调用方
try
{
    await DoSomethingAsync();
}
catch (Exception ex)
{
    // 这里能捕获到
}

第二个反模式是不必要的 async/await 包装。如果方法体只是 return 一个 Task,没有真正的 await,那就直接返回 Task 不要包 async。这样可以省一次状态机生成,性能略好,代码也更清爽。

// 反面: 多余的 async/await
public async Task GetCountAsync()
{
    return await _db.Counts.CountAsync();  // 多此一举
}

// 正面: 直接返回 Task
public Task GetCountAsync()
{
    return _db.Counts.CountAsync();
}

// 但: 如果有 try/catch 或 using, 必须 async/await
public async Task GetCountWithDisposalAsync()
{
    using var scope = _serviceProvider.CreateAsyncScope();
    // 这里必须 await, 否则 scope 提前释放
    return await scope.ServiceProvider.GetRequiredService().CountAsync();
}

第三个反模式是串行的 await。如果两个 Task 互相独立,应该用 Task.WhenAll 并行等待,而不是串行 await。这种优化在 IO 密集型代码里效果显著,把两个独立的 100ms 调用从串行 200ms 变成并行 100ms。

// 反面: 串行 (200ms)
var user = await GetUserAsync(id);
var orders = await GetOrdersAsync(id);

// 正面: 并行 (100ms)
var userTask = GetUserAsync(id);
var ordersTask = GetOrdersAsync(id);
await Task.WhenAll(userTask, ordersTask);
var user = await userTask;
var orders = await ordersTask;

四种 async 死锁场景对比

线程池耗尽的连锁反应

这次死锁的连锁后果是线程池耗尽。每个请求进来都尝试运行那段死锁代码,线程被卡住,线程池里的线程逐渐被消耗光,新请求只能排队等待。线程池的默认配置是按 CPU 核数动态分配,我们的机器是 8 核,初始线程数 8,最多扩到几百,但扩展速度很慢(每秒只加 1-2 个),根本跟不上请求涌入速度。

// 排查线程池状态的代码
ThreadPool.GetAvailableThreads(out int workerThreads, out int ioThreads);
ThreadPool.GetMaxThreads(out int maxWorker, out int maxIo);
Console.WriteLine($"Worker: {workerThreads}/{maxWorker}");
Console.WriteLine($"IO: {ioThreads}/{maxIo}");

// 应急扩展线程池下限 (临时缓解, 不解决根本问题)
ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 100);

线程池耗尽时,任何依赖线程的操作都会变慢,包括日志写入、APM 上报、健康检查。我们事故时甚至连 Kubernetes 的 liveness probe 都失败了,导致容器被反复重启,雪上加霜。后来给 liveness probe 单独留了线程池(用专用的 BackgroundService),才避免了这种"健康检查失败导致服务被杀"的次生事故。

第二根线:HttpClient 滥用引发的端口耗尽

那次复盘里我们顺手扒了另一个让事故被放大的根因——HttpClient 滥用。当时排查到一半,SRE 同学跑了一行 ss -tan | grep TIME_WAIT | wc -l,机器上 TIME_WAIT 状态的连接竟然飙到了两万八千个,几乎吃光了可用临时端口。原因翻代码一眼就看出来:有几个上游调用直接 new HttpClient(),每个请求都新建一个,用完 dispose,socket 进入 TIME_WAIT 等内核回收(默认 60 秒),并发一上来端口就被吃光。这条线和前面的 async 死锁是互相放大的:端口耗尽让新连接握手变慢,握手慢让请求阻塞时间变长,阻塞变长让 ThreadPool 更早进入饥饿。

HttpClient 的正确用法在官方文档里早就写得明明白白:用 IHttpClientFactory 注入。这玩意儿从 .NET Core 2.1 就有了,但很多老项目里因为历史包袱仍在裸 new。HttpClientFactory 的核心价值是复用底层 HttpMessageHandler——也就是连接池——同时帮你管理 handler 生命周期(默认两分钟回收一次,既复用又能感知 DNS 变更),还能一行配出超时、重试、熔断。

// 反模式 (事故源头之一): 每个调用都 new HttpClient
public async Task<string> CallUpstreamLegacy()
{
    using var http = new HttpClient();  // 看起来 using 很干净
    http.Timeout = TimeSpan.FromSeconds(3);
    return await http.GetStringAsync("https://upstream/api");
    // dispose 后 socket 进 TIME_WAIT, 大并发下端口被吃光
}

// 修法: Program.cs 注册 typed client (推荐)
builder.Services.AddHttpClient<IUpstreamClient, UpstreamClient>(c =>
{
    c.BaseAddress = new Uri("https://upstream/");
    c.Timeout     = TimeSpan.FromSeconds(3);  // 显式设超时, 默认 100s 是坑
    c.DefaultRequestHeaders.Add("User-Agent", "order-service/1.4");
})
.AddPolicyHandler(GetRetryPolicy())          // Polly 重试
.AddPolicyHandler(GetCircuitBreakerPolicy()); // Polly 熔断

static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy() =>
    HttpPolicyExtensions
        .HandleTransientHttpError()
        .WaitAndRetryAsync(3, attempt => TimeSpan.FromMilliseconds(200 * attempt));

// 业务里通过 DI 拿
public class UpstreamClient : IUpstreamClient
{
    private readonly HttpClient _http;
    public UpstreamClient(HttpClient http) => _http = http;

    public async Task<Order> GetOrder(long id, CancellationToken ct)
    {
        using var resp = await _http.GetAsync($"orders/{id}", ct)
                                    .ConfigureAwait(false);
        resp.EnsureSuccessStatusCode();
        return await resp.Content
            .ReadFromJsonAsync<Order>(cancellationToken: ct)
            .ConfigureAwait(false);
    }
}

这次清理之后我们把所有 new HttpClient 加进了 banned API 列表,用 BannedApiAnalyzers 直接在编译期挡掉。生产上观察了一周,同样负载下机器的 TIME_WAIT 数量稳定在 2000 以内(事故时是两万八),而且因为 SocketsHttpHandler 内部维护连接池,跨请求复用已经握手好的 TCP 连接,上游调用平均延迟下降了大约 18 毫秒。这个"顺手修"的优化最后比死锁修复本身带来的稳态收益还要明显。

临时止血:调大 ThreadPool.MinThreads

事故现场我们没法在十分钟里把所有 async 死锁和 HttpClient 滥用都改完,必须先止血。临时方案是把 ThreadPool 的 MinThreads 一次性调大,让池子不需要慢慢扩容(默认每秒只能加 1-2 个线程,雪崩时根本跟不上)。但这是救急药不是治本药:线程多了占内存(每个线程默认 1MB 栈),也增加上下文切换成本,理想稳态是线程数与 vCPU 同量级,而不是几百几千。

// Program.cs 启动早期 (业务代码之前) 调:
ThreadPool.SetMinThreads(workerThreads: 200, completionPortThreads: 200);

// 也可以通过环境变量 (.NET 6+, 容器场景更友好):
// DOTNET_ThreadPool_MinThreads=200

// 监控 ThreadPool 利用率, 防止又被打爆
var timer = new Timer(_ =>
{
    ThreadPool.GetAvailableThreads(out int w, out int io);
    ThreadPool.GetMaxThreads(out int maxW, out int maxIo);
    _logger.LogInformation("ThreadPool worker={U}/{M} io={IU}/{IM}",
        maxW - w, maxW, maxIo - io, maxIo);
}, null, TimeSpan.Zero, TimeSpan.FromSeconds(10));

这个数字怎么选?我们的经验是先按"峰值 QPS × 单请求平均阻塞时长(秒)"算一个粗略下限,再加 50% 余量。比如 2500 QPS × 60ms 平均阻塞 = 150 线程,加 50% 余量取 230,我们最终设了 200。设完之后立刻观察 ThreadCount 走势:如果还在持续上涨,说明根因没消除,治标无效;如果稳定在某个数字附近,说明 MinThreads 设得够。但一旦死锁修法、HttpClientFactory 改造、ConfigureAwait(false) 全部落地,这个值要逐步往回压,长期保持几百个空跑线程是不健康的。我们最终在重构完成两周后把 MinThreads 调回了 32,稳态线程数也稳定在 18 个左右。

修复后真实基准:五种配置组合对比

事故复盘后我们做了一份完整基准,在 4 vCPU 8GB 的 Pod 上分别跑五种配置组合,负载是 2500 QPS 持续 10 分钟,记录 P50 / P99 / 平均 ThreadPool 线程数 / TIME_WAIT 数量。结果非常清晰,只有"全程真异步 + HttpClientFactory + ConfigureAwait(false)"才是治本方案,任何单项修法都只能缓解。

从这个表能看出几件事。第一,只调 MinThreads 能止血但治标不治本,P99 还在 1.8 秒,而且白白多养几百个线程,服务器内存被吃掉一大块;第二,HttpClientFactory 把端口耗尽问题彻底解决,但 ThreadPool 仍在 280 高位,因为死锁还在,所以单点修复并不能让 P99 完全回到健康水位;第三,把 .Result 全部改成 await 才是性能拐点,ThreadPool 线程数直接掉到 18 个,因为真异步等待完全不占线程,这一项才是治本;第四,ConfigureAwait(false) 在 ASP.NET Core 里增量收益确实小(没有 SyncContext),它真正的价值是给库代码加,以及防御性兼容旧宿主,这种"以防万一"在跨团队 SDK 项目里非常关键。

更深层的 Task 调度细节

这次事故让我们深入研究了 .NET 的 Task 调度机制。Task 默认在 ThreadPool 上执行,但 TaskScheduler 可以被自定义,某些库会用自己的 TaskScheduler 控制并发度。如果一段代码同时混用了多个 TaskScheduler,排查问题会非常困难。我们建议除非有强需求,不要自定义 TaskScheduler,直接用默认的 ThreadPool 就好。

// 看当前 Task 的执行环境
public async Task DebugTaskContext()
{
    Console.WriteLine($"Thread: {Thread.CurrentThread.ManagedThreadId}");
    Console.WriteLine($"IsThreadPoolThread: {Thread.CurrentThread.IsThreadPoolThread}");
    Console.WriteLine($"SyncContext: {SynchronizationContext.Current?.GetType().Name ?? "null"}");
    Console.WriteLine($"TaskScheduler: {TaskScheduler.Current.GetType().Name}");

    await Task.Yield();  // 强制返回 ThreadPool

    Console.WriteLine($"After yield, Thread: {Thread.CurrentThread.ManagedThreadId}");
}

Task.Yield() 是个被低估的 API,它强制把当前方法的剩余部分排到 ThreadPool 队列尾部,让其他 Task 有机会执行。在循环里做大量同步计算的场景下,适当插入 Task.Yield() 可以避免某个 Task 长时间霸占线程。但要注意 Task.Yield 也有性能开销,不要滥用。

IAsyncDisposable 的正确用法

C# 8.0 引入了 IAsyncDisposable,用于"需要异步释放资源"的场景。典型场景是关闭网络连接、刷新缓冲区到磁盘、提交事务等,这些操作本身是异步的,不应该在同步的 Dispose 里硬等。但很多开发者还在用 IDisposable 包 .Result,这就是埋雷。

// 正确: 实现 IAsyncDisposable
public class AsyncConnection : IAsyncDisposable
{
    private readonly Socket _socket;
    private bool _disposed;

    public async ValueTask DisposeAsync()
    {
        if (_disposed) return;
        _disposed = true;
        // 异步关闭, 不阻塞
        await _socket.DisconnectAsync(reuseSocket: false);
        _socket.Dispose();
    }
}

// 调用方: await using
await using (var conn = new AsyncConnection())
{
    // 用 conn
}  // 自动 await DisposeAsync

await using 是 C# 8.0 的语法糖,会在作用域结束时 await DisposeAsync。它比手动调用 DisposeAsync 简洁,而且不会忘记调。任何持有 IO 资源的类都应该考虑实现 IAsyncDisposable,这是现代 C# 异步编程的最佳实践。EF Core 的 DbContext、HttpClient、各种 Stream 都实现了 IAsyncDisposable,可以直接 await using。

团队立的几条规矩

1. 禁止任何同步阻塞 async 方法的写法 (.Result / .Wait() / GetAwaiter().GetResult())。
2. 库代码全程 ConfigureAwait(false), 应用代码可以省略。
3. 禁止 async void, 除了事件处理器, 必须用 async Task。
4. 所有 Task 必须被 await 或显式赋值给 _ 表示 fire-and-forget。
5. fire-and-forget 必须用 try/catch + 日志, 不允许吞异常。
6. 异步初始化用 IHostedService 或工厂方法, 禁止在构造函数里阻塞。
7. 实现 IAsyncDisposable 的资源类使用 await using。
8. CI 强制启用 async 相关 analyzer (Microsoft.VisualStudio.Threading + AsyncFixer)。
9. 独立 Task 用 Task.WhenAll 并行, 不要串行 await。
10. 关键路径有 APM 监控, Task 等待时间超过阈值告警。

排查 async 死锁的工具链

排查 async 死锁需要一套工具链。第一个是dotnet-dump,可以抓进程 dump,然后用 dotnet-dump analyze 看线程栈,识别哪些线程在等 Task。第二个是dotnet-trace,可以采集运行时事件,看 ThreadPool 和 Task 的调度过程。第三个是PerfView,Microsoft 出的性能分析工具,功能强大但学习曲线陡。这几个工具配合用,基本能定位绝大多数 async 死锁问题。

# 抓 dump
dotnet-dump collect -p 

# 分析
dotnet-dump analyze core_xxx.dmp
> clrthreads -live  # 看所有托管线程
> clrstack          # 看当前线程栈
> dumpheap -stat    # 看堆上对象统计
> syncblk           # 看锁竞争情况

# 采集运行时事件
dotnet-trace collect -p  --providers Microsoft-Windows-DotNETRuntime

除了官方工具,还有几个第三方工具值得了解。dotMemory 是 JetBrains 的内存分析工具,UI 友好,看大堆 dump 比 PerfView 直观得多。dotTrace 是同公司的性能分析工具,可以采样和追踪两种模式,排查 CPU 热点非常方便。这些工具都是付费的,但对企业项目来说,买几个 license 比工程师加班排查问题划算得多。

给同行的几条建议

第一条建议是async/await 不是"普通函数加个关键字"。它背后是一整套状态机生成、ThreadPool 调度、SynchronizationContext 流转的复杂机制,理解这些机制才能写出正确的异步代码。建议每个 C# 开发者都读一读 Stephen Toub 的几篇 async 深度文章,网上免费可得,信息密度极高。

第二条建议是能用 ASP.NET Core 就别用 ASP.NET Framework。Core 默认没有 SynchronizationContext,大量死锁场景天然消失。Framework 时代的"async 死锁"问题在 Core 上几乎不存在,迁移到 Core 本身就是一次安全升级。如果还在用 Framework,这是个值得投入的迁移项目。

第三条建议是把 analyzer 当成必备基础设施。Roslyn analyzer 的能力非常强,几乎可以静态发现所有常见的 async 反模式。在 CI 里强制启用,把问题挡在合并之前,比线上排查代价小一万倍。这种工具的投入产出比极高,所有 C# 项目都应该用。

第四条建议是线程池要主动配置而不是被动接受默认值。线程池的最小线程数默认很低(等于 CPU 核数),在流量突增时扩展速度慢,容易出现卡顿。生产环境应该根据负载特征显式 SetMinThreads,避免被默认值坑。这个调优在压测时容易发现,生产前必做。

CancellationToken 全链路:把"客户端断开"传到底层

这次事故还顺手暴露了另一个普遍问题:CancellationToken 没有一路传到底。前端 5 秒超时之后客户端早就断开,但服务端的请求线程仍在傻乎乎地等下游返回、查数据库、序列化结果,等到最后才发现"哦客户端不要了",白白浪费了一次完整的处理。在 ThreadPool 已经紧张的情况下,这种"明明可以提前释放却没释放"的浪费会被无限放大,变成压死骆驼的最后一根稻草。

// 正确做法: Controller 接 token, 每一层都传透
[HttpGet("order/{id}")]
public async Task<ActionResult<OrderDto>> Get(
    long id,
    CancellationToken ct)   // ASP.NET Core 会自动注入 HttpContext.RequestAborted
{
    var order = await _orderClient.GetOrder(id, ct);
    var payment = await _paymentClient.GetPayment(order.PayId, ct);
    return new OrderDto(order, payment);
}

// EF Core 调用必须传 ct, 否则 SQL 不会被取消
public async Task<Order> QueryAsync(long id, CancellationToken ct)
{
    return await _db.Orders
        .AsNoTracking()
        .FirstOrDefaultAsync(o => o.Id == id, ct);  // ← ct 必传
}

// Redis (StackExchange.Redis) 也支持 cancellation
await _cache.StringGetAsync(key).WaitAsync(ct);

这条"全链路传 ct"的规矩落地一个月,我们观察到大促时段服务端有效负载下降了大约 14%(被取消的请求直接 short-circuit,不再消耗下游资源),数据库的"查询执行中"会话数也明显减少。这是个几乎零成本的优化,但很多项目里就是没人坚持,只因为"老代码方法签名里没有 ct,改起来牵一发动全身"——其实只要从入口开始按顺序推,大半年就能改完。

EF Core 异步常见误区

顺便提一下 EF Core 上几个我们也踩过的坑,都和异步有关。第一个是同步方法和异步方法混用:同一个 DbContext 上既调 .ToList() 又调 .ToListAsync(),看起来都能跑,但底层的连接管理会出现奇怪状态,我们见过一次"前一个查询的 result reader 没读完就开了下一个"的并发异常。规矩:一个 DbContext 在整个请求里要么全同步要么全异步,我们选全异步。

第二个是SaveChangesAsync 漏 await:写成 _db.SaveChangesAsync();(没 await)看起来人畜无害,实际上 Task 直接 fire-and-forget,异常吃掉,事务可能没真正提交。这种 bug 极其隐蔽,因为 90% 时间业务能跑通,只有偶发 race 时才丢数据。Roslyn analyzer(CA2007 / VSTHRD110)能挡住这类问题,务必开启 warning-as-error。第三个是异步查询里用 Include 不当:Include 拉太多导航属性会让 SQL 巨复杂,即使是 async 调用,数据库返回时间一长照样把线程的 await 堆栈拉得很长,跟 ThreadPool 不直接相关但很影响 P99。我们的规矩是 Include 超过 2 层必须 PR 评审注释解释,否则一律拆成多次查询并行(Task.WhenAll)。

跟其他语言的对比

async/await 不是 C# 独有的概念,JavaScript、Python、Rust、Kotlin 等语言都有类似的机制,但实现细节差异很大。JavaScript 是单线程的,async 本质是事件循环里的 Promise,没有 SynchronizationContext 概念,但有自己的死锁可能(比如 await 一个永远 pending 的 Promise)。Python 的 asyncio 是协程模型,跑在单线程的 event loop 上,死锁问题主要是阻塞调用阻塞了 loop。

Rust 的 async 是 zero-cost abstraction,需要显式 spawn 到 runtime(比如 tokio),没有隐式的上下文捕获,概念上最清晰但学习曲线最陡。Kotlin 的协程是结构化并发,有明确的 CoroutineScope 和取消语义,比 C# 的 Task 更安全。每种语言都有自己的特色和坑,跨语言开发者要特别小心不要把习惯带错。

团队推广 async 规范时遇到的阻力

这套规矩推广到全公司时遇到了几个真实阻力。第一个阻力来自遗留代码的迁移成本。我们有几个老项目用了大量 .Result 写法,要全部改成 await 需要把方法签名改成 async,这种改动是病毒式的——一个地方改了,调用它的所有地方都要改。我们的策略是新代码严格执行,老代码遇到 bug 时顺便重构,半年下来基本清理干净。

第二个阻力来自"加 ConfigureAwait(false) 太啰嗦"的抱怨。每个 await 后面都跟一个 .ConfigureAwait(false),代码看起来确实丑。我们的折中是用 .editorconfig + analyzer 半自动加,IDE 提示缺失,可以一键修复。这种工具支持让"做正确的事"变得不那么痛苦,大家接受度高很多。

第三个阻力来自性能担忧。有人觉得 async/await 有运行时开销,简单方法不如同步快。这种说法在某些极端场景下成立(比如调用频率几百万次每秒的纯计算),但绝大多数业务场景下根本不是瓶颈。我们做了压测对比,async 比同步慢的部分通常是几纳秒级别,对业务无影响。这种"过早优化"的担忧不应该影响代码质量。

真实收益数据

事故复盘的几点反思

第一点反思是异步编程的复杂度被严重低估。async/await 看起来很简单,加个关键字而已,但底层是一整套状态机和调度机制。不理解就用,容易写出"看起来对但隐藏死锁"的代码。团队里应该有几个 async 专家,负责 code review 时把关,避免新人踩坑。

第二点反思是"上线前没测试到的代码路径必然出问题"。那段死锁代码是上线前一天临时加的,没经过完整的压测,直接上了生产。生产流量一上,死锁立刻暴露。这告诉我们任何新代码必须经过压测验证,即使看起来"只是个小改动",在高并发下也可能是大问题。

第三点反思是工具链可以拯救人脑。事故之后我们加了 analyzer,后来几个潜在的同类问题都被 analyzer 在 build 阶段挡住了,从未到达生产。工具能做的事情就让工具做,人脑要集中在业务逻辑和架构设计上,不应该浪费在"记住所有反模式"这种事上。

第四点反思是容器化场景下默认值更要主动调。我们的 Pod 是 4 vCPU,.NET 默认按宿主感知 CPU 数设 ThreadPool MinThreads,但 K8s 的 cpu limit 不一定能被准确识别(尤其是老内核的 cgroup v1 场景),实际值可能跟预期差很远。生产前必须在容器里 print 一次 Environment.ProcessorCount 和 ThreadPool.GetMinThreads,确认数值符合预期。这点小事被忽略,会在最关键的时刻给你一刀。

总结

这次 ASP.NET Core async 死锁事故是 C# 开发者最容易踩的坑之一,核心教训是禁止任何形式的同步阻塞 async 方法,库代码全程 ConfigureAwait(false),启动任务用 IHostedService,异常处理彻底化,analyzer 把关。这些规矩做到位,async 死锁基本可以杜绝。

希望这篇能给正在用 C# 做后端的同行一些参考。async/await 是个强大的工具,但需要正确使用。理解 SynchronizationContext、TaskScheduler、ThreadPool 这些底层概念,配合 analyzer 和监控,可以让你的异步代码既正确又高效。如果你的项目还在用 .Result 或 .Wait(),请立刻清理,不要等到生产事故。

最后想说的是,async 死锁这种问题在排查时极其痛苦,但修复后获得的稳定性提升是巨大的。把这些基础打好,你的服务可以稳定运行多年不出问题,团队的精力可以集中在业务创新上,而不是反复救火。这种"基础工程的红利"是长期主义的最好体现,值得每个团队认真投入。

—— 别看了 · 2026