接口慢，不一定是数据库慢。很多系统在高峰期的核心问题，是异步链路写法导致线程池被慢慢耗空。
这类问题最麻烦的地方在于：
- 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 + 有界队列 + 固定并发消费者。
csharp
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 层只负责入队，不直接做重任务：
csharp
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"，而是把系统并发控制住。
当你用有界队列、固定并发、超时取消把流量压在可承载区间，线程池饥饿就不会轻易出现。稳定性，永远比一次压测峰值更有工程价值。