接口慢，不一定是数据库慢。很多系统在高峰期的核心问题，是异步链路写法导致线程池被慢慢耗空。

这类问题最麻烦的地方在于：

• CPU 不一定打满
• 错误日志不一定明显
• 本地压测可能复现不出来

这篇文章围绕一个目标展开：让异步代码在高并发下“稳态运行”，而不是“平时很快，高峰崩盘”。

1. 问题背景：为什么会出现线程池饥饿

常见触发方式：

• 在 ASP.NET Core 请求中使用 .Result / .Wait()
• 把 I/O 任务包进 Task.Run
• 下游服务抖动时无限制并发重试

你以为是在“提速”，实际上是在制造排队。

2. 原理解析

2.1 Task 与调度

Task 表示异步操作，不等于“新线程”。多数场景下，它复用线程池线程在不同 I/O 等待阶段切换。

2.2 ValueTask 的边界

ValueTask 适合高频且经常同步完成的路径，减少分配；但它有使用约束，不应随意替换所有 Task。

2.3 线程池饥饿

当大量请求线程被阻塞等待 I/O，线程池补充速度跟不上时，后续请求只能排队，RT 开始抖动。

2.4 背压

背压本质是“主动限制进入系统的工作量”，通过队列边界和并发上限把峰值削平，换取整体稳定。

3. 示例代码：有边界的后台处理模型

下面是一个可落地的最小模型：Channel + 有界队列 + 固定并发消费者。

using System.Threading.Channels;

public sealed record ExportJob(Guid JobId, long UserId, DateTime CreatedAt);

public sealed class ExportQueue
{
    private readonly Channel<ExportJob> _channel = Channel.CreateBounded<ExportJob>(
        new BoundedChannelOptions(500)
        {
            FullMode = BoundedChannelFullMode.DropWrite,
            SingleWriter = false,
            SingleReader = false
        });

    public bool TryEnqueue(ExportJob job) => _channel.Writer.TryWrite(job);
    public IAsyncEnumerable<ExportJob> ReadAllAsync(CancellationToken ct) => _channel.Reader.ReadAllAsync(ct);
}

public sealed class ExportWorker : BackgroundService
{
    private readonly ExportQueue _queue;
    private readonly ILogger<ExportWorker> _logger;
    private readonly SemaphoreSlim _concurrency = new(4);

    public ExportWorker(ExportQueue queue, ILogger<ExportWorker> logger)
    {
        _queue = queue;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var job in _queue.ReadAllAsync(stoppingToken))
        {
            _ = ProcessOneAsync(job, stoppingToken);
        }
    }

    private async Task ProcessOneAsync(ExportJob job, CancellationToken ct)
    {
        await _concurrency.WaitAsync(ct);
        try
        {
            await Task.Delay(200, ct); // 模拟 I/O
            _logger.LogInformation("export done {JobId}", job.JobId);
        }
        catch (OperationCanceledException)
        {
            // 正常退出
        }
        finally
        {
            _concurrency.Release();
        }
    }
}

API 层只负责入队，不直接做重任务：

app.MapPost("/api/exports", (ExportQueue queue, long userId) =>
{
    var job = new ExportJob(Guid.NewGuid(), userId, DateTime.UtcNow);
    return queue.TryEnqueue(job)
        ? Results.Accepted($"/api/exports/{job.JobId}", new { job.JobId })
        : Results.StatusCode(StatusCodes.Status429TooManyRequests);
});

4. 工程实践建议

4.1 异步红线

• 请求链路禁用 .Result / .Wait()
• I/O 场景禁用 Task.Run 伪异步
• 所有下游调用必须设置超时与取消令牌

4.2 并发控制前置

把限流和队列边界放在入口层，不要等到数据库或第三方 API 才发现过载。

4.3 监控维度

至少监控：

• 线程池可用线程数
• 队列长度
• 请求超时率
• 重试次数

4.4 ValueTask 使用准则

只在以下条件同时满足时使用：

• 方法调用极高频
• 同步完成概率高
• 团队理解其使用约束

否则优先 Task，维护成本更低。

5. 总结

异步编程的核心不是“把方法都改成 async”，而是把系统并发控制住。

当你用有界队列、固定并发、超时取消把流量压在可承载区间，线程池饥饿就不会轻易出现。稳定性，永远比一次压测峰值更有工程价值。