.NET 10 线程池：从运行原理到饥饿诊断与调优

线程池经常在两种情况下进入开发者视野：一种是学习 Task.Run 和 async/await 时，另一种是线上服务 CPU 并不高，请求却越来越慢时。前一种容易让人误以为“一个 Task 对应一个线程”，后一种又容易让人把“增加线程数”当成通用解法。

这两个认识都不准确。线程池负责管理和复用线程，Task 表示一个可能尚未完成的操作，await 负责组织异步控制流。它们彼此有关，但不是同一个抽象。

本文以 .NET 10 为运行环境，重点建立现代 .NET 线程池的工作模型，并解释线程池饥饿为什么发生、怎样判断以及应该从哪里修复。文中大部分机制并非 .NET 10 新增；涉及版本变化时会单独说明。

🧵 为什么需要线程池

线程是执行代码的基本载体，但线程并不是没有成本的资源。创建和销毁线程需要进入操作系统，线程还需要栈空间，并参与内核调度。如果每一个短小工作都创建一个新线程，应用很快就会把大量时间和内存消耗在线程管理上。

线程数量也不是越多越好。可运行线程多于处理器实际能够并行执行的数量后，操作系统需要更频繁地保存和恢复线程上下文。多个线程还会竞争锁、缓存和下游资源，最终可能让吞吐量下降。

线程池解决的是这类通用问题：

复用已经创建的线程，减少反复创建和销毁线程的成本。
将暂时无法执行的工作放入队列，而不是为每个工作无限创建线程。
根据负载和完成速度动态调整线程数量，在并行度与调度成本之间寻找平衡。
为 TPL、计时器回调、注册等待、异步 I/O 完成以及部分网络操作提供统一的执行资源。

一个进程只有一个托管线程池。线程池线程属于后台线程，不会仅因为线程池中还有工作线程就阻止进程退出。

线程池适合大量、相对短小并且彼此独立的工作。如果任务需要固定线程身份、特殊优先级、前台线程，或者会长时间同步阻塞，专用线程或其他后台处理模型可能更合适。

🧠 先建立一个心智模型

可以先忽略具体实现，把线程池理解成“工作队列 + 一组可复用线程 + 动态调节器”。

这里需要区分四个经常混在一起的数字：

工作项数量： 一共提交了多少工作。
队列长度： 还有多少工作正在等待执行。
线程数量： 线程池当前管理了多少线程。
可用线程数量： 线程池距离配置上限还剩多少可用于处理工作的容量。

提交 1 万个工作项并不意味着线程池会创建 1 万个线程。大量工作可以留在队列中，由少量线程逐步处理。反过来，线程池里存在很多线程也不意味着它们此刻都在执行用户代码。

全局队列、线程本地队列与工作窃取

现代 .NET 线程池并不只有一条简单的先进先出队列。为了降低多个线程同时访问同一队列的竞争，运行时可以使用全局队列和线程本地队列。线程池线程产生的新工作常常可以进入本地队列；当前线程没有工作时，还可以从其他线程的本地队列“窃取”工作。

这个模型有助于理解为什么并行任务能够减少共享队列竞争，也能解释为什么工作执行顺序通常不应被依赖。但这些属于运行时实现层面的设计，不是业务代码可以依赖的稳定调度契约。除非 API 明确保证顺序，否则不要根据某次实验推断工作一定先进先出。

全局队列线程本地队列空闲线程从队尾窃取工作

🧩 Thread、ThreadPool、Task 与 async/await

下面几个概念处在不同层级：

概念	表示什么	是否必然创建或持续占用线程
`Thread`	一个实际的托管线程对象，对应可被操作系统调度的执行线程	创建并启动后会使用独立线程
`ThreadPool`	运行时管理和复用线程的公共设施	按需管理线程，不为每个工作创建一个线程
`Task`	一个可能已经完成、正在运行或未来完成的操作	不一定；它可以表示计算、I/O、计时或手动完成的结果
`ValueTask`	一种可等待的值类型，可以直接携带结果，也可以包装 Task 或其他异步源	不一定；它优化的是部分场景下的分配，不是线程调度
`Task.Run`	把委托调度到默认任务调度器执行	通常使用线程池线程执行委托
`async`	允许方法使用异步状态机的语言标记	本身不会创建线程
`await`	暂停当前异步方法，完成后继续后续逻辑	不保证创建新线程，也不保证一定切换线程

Task 不是线程

Task 的核心含义是“一个最终会完成的操作”。下面这些 Task 的线程关系完全不同：

Task<int> completed = Task.FromResult(42);
Task delay = Task.Delay(1_000);
Task calculation = Task.Run(() => Calculate());

Task.FromResult 在创建时已经完成，不需要线程执行计算。
Task.Delay 表示一段异步等待，等待期间不需要让线程一直停在那里计时。
Task.Run 的委托需要真正执行代码，默认会在线程池线程上运行。

因此，“有几个 Task”不能直接回答“用了几个线程”。一个 Task 可能不需要线程等待，多个 Task 也可能在同一个线程上先后执行。

await 也不等于切换线程

执行到 await 时，如果被等待的操作已经完成，方法可以直接继续执行；如果操作尚未完成，异步方法保存当前状态并把控制权交还给调用方。等操作完成后，后续代码再由合适的执行上下文继续运行。

真正的异步 I/O 最重要的价值不是“换一条线程等待”，而是等待期间不持续占用工作线程。网络、文件或数据库操作完成后，仍然需要线程执行完成通知和后续业务代码，但线程不必在整个等待时间里被阻塞。

控制台程序和 ASP.NET Core 默认没有传统桌面 UI 那样的 SynchronizationContext，延续代码通常会在线程池线程上执行。不过仍然不应把“await 后一定换线程”写进业务假设；线程切换不是 await 的语义保证。

Task 从创建到完成经历了什么

Task 与线程池的关系，取决于 Task 代表的工作来自哪里。对于 Task.Run 提交的 CPU 计算，委托会经过默认任务调度器进入线程池队列，再由工作线程执行。

Task.Run 明确使用 TaskScheduler.Default，默认调度器使用 .NET 线程池。这里不需要说“一个 Task 拥有一个线程”：Task 只记录操作的完成、结果、异常和取消状态，真正执行委托的是某个线程池线程。线程执行完委托后可以继续领取其他工作，Task 则保留为已经完成的结果对象。

真正的异步 I/O 则在启动操作后返回未完成的 Task，等待期间不持续占用工作线程，直到 I/O 完成后再让后续代码获得执行机会。

工作线程正在执行代码I/O 等待，不持续占用工作线程

异步方法在遇到第一个尚未完成的 await 之前仍然会同步执行。被等待的 Task 如果已经完成，后续代码也可以直接在当前线程继续，而不必先进入线程池队列。如果 Task 尚未完成，编译器生成的状态机会注册延续逻辑；Task 完成后，延续逻辑按照当前上下文和 awaiter 的规则获得执行机会。

这意味着“Task 已完成”主要是一种状态通知：等待者现在可以继续。它不保证后续代码一定被包装成新的 Task，也不保证一定创建、占用或切换到某一条线程。

Task 的完成状态、异常与取消

Task 最终有三种终态：

RanToCompletion：操作正常完成，Task<T> 可以提供结果。
Faulted：操作抛出异常，异常被保存在 Task 中。
Canceled：操作按照协作式取消约定结束。

通常不需要循环读取 Task.Status 等待状态变化，直接 await 即可同时处理完成通知和结果传播。异常行为则需要注意同步等待与异步等待的差异：

try
{
    var customer = await GetCustomerAsync(id);
}
catch (CustomerNotFoundException exception)
{
    Console.WriteLine(exception.Message);
}

await task 和 task.GetAwaiter().GetResult() 会重新抛出原始异常；task.Wait() 和 task.Result 会阻塞当前线程，并通过 AggregateException 包装任务异常。后两种写法不仅让异常处理更复杂，也是本文线程池饥饿问题中的高风险同步等待。

没有被 await、返回或显式观察的“即发即弃”Task 还可能隐藏异常和任务生命周期。除事件处理器等特定边界外，异步方法应返回 Task 或 Task<T>，调用方应保留并观察这个结果。

取消也不会强行终止线程：

using var source = new CancellationTokenSource(TimeSpan.FromSeconds(2));

try
{
    await DownloadAsync(source.Token);
}
catch (OperationCanceledException) when (source.IsCancellationRequested)
{
    Console.WriteLine("操作已取消");
}

CancellationToken 表达的是取消请求。操作必须主动观察 Token、停止工作并按约定结束；已经执行的同步阻塞代码不会仅因为调用了 Cancel() 就自动释放线程。对于尚未开始的 Task.Run 工作，Token 可能阻止委托开始；工作一旦运行，仍然需要委托自身协作。

Task.WhenAll 不等于创建更多线程

Task.WhenAll 创建一个代表“所有输入 Task 都已完成”的组合 Task，本身不会阻塞调用线程，也不会为每个输入 Task 创建线程：

var requests = customerIds
    .Select(GetCustomerAsync)
    .ToArray();

var customers = await Task.WhenAll(requests);

上例在调用 GetCustomerAsync 时启动各个操作，WhenAll 只负责组合完成状态。100 个真正的异步 I/O Task 在等待期间不等于占用 100 个线程，但它们仍可能同时占用 100 个连接、请求配额或下游处理槽位。因此“不占线程”不等于“并发不需要限制”。

如果任一输入 Task 失败，组合 Task 会进入 Faulted 状态；没有失败但至少一个被取消时，它会进入 Canceled 状态。直接 await WhenAll 时会重新抛出其中一个异常；需要查看全部失败时，应先保留组合 Task，再检查它的 Exception.InnerExceptions。

Task.Run 接收异步委托时会自动展开内部 Task：

Task operation = Task.Run(async () =>
{
    await SaveAsync();
});

这里的 operation 表示整个异步委托完成，而不是只表示委托运行到第一个 await。不过如果 SaveAsync 本来就是真正的异步 I/O，通常直接 await SaveAsync() 即可，没有必要先用 Task.Run 在线程池中再包一层。

ValueTask 解决的不是线程问题

Task 和 Task<T> 是引用类型。高频调用的异步 API 如果经常能够同步完成，例如数据大部分时间可以直接从内存缓存中取得，为每次调用创建 Task 对象可能形成可测量的堆分配。ValueTask 和 ValueTask<T> 是值类型，可以直接携带同步结果，也可以包装一个 Task，或连接到可复用的 IValueTaskSource。

static ValueTask<string> GetMessageAsync(bool cacheHit)
{
    if (cacheHit)
    {
        return ValueTask.FromResult("cached");
    }

    return new ValueTask<string>(LoadMessageAsync());
}

static async Task<string> LoadMessageAsync()
{
    await Task.Delay(100);
    return "loaded";
}

命中缓存时，ValueTask<string> 可以直接包含字符串结果；未命中时，它包装真正的异步 Task。这个差异优化的是返回对象的分配，不改变工作的执行位置：同步完成路径可能不需要线程池调度，包装的 CPU Task 仍然可能在线程池执行，包装的异步 I/O 仍然可以在等待期间不占用工作线程。

默认使用 Task<T>测量后再考虑 ValueTask<T>

对比	`Task<T>`	`ValueTask<T>`
类型	引用类型	值类型
多次 await	可以	调用方默认只能安全消费一次
多个调用方共享	适合	不应直接共享同一个实例
与 `WhenAll` 等组合	直接使用	通常需要先转换为 Task
典型选择	默认选择，语义简单	高频、经测量存在分配压力且经常同步完成的 API

调用任意 API 返回的 ValueTask 时，应假设它只能被消费一次，并优先直接 await：

var message = await GetMessageAsync(cacheHit: true);

不要把 ValueTask 长期保存到字段，不要在完成前读取 .Result，也不要默认对同一个实例 await 多次。某些 ValueTask 恰好包装 Task 或直接结果时，多次消费看似能够运行，但它也可能来自可复用的 IValueTaskSource；再次消费可能抛出异常、读取已被复用的状态或造成数据错误。

如果确实需要让多个调用方等待、重复 await，或者传给只接受 Task 的组合 API，应只调用一次 AsTask()，然后共享得到的 Task：

ValueTask<string> pending = GetMessageAsync(cacheHit: false);
Task<string> shared = pending.AsTask();

var first = await shared;
var second = await shared;

ValueTask 自身比一个对象引用包含更多状态，异步状态机也可能因此变大；如果操作几乎总是异步完成，它往往仍需包装 Task，并不能带来预期收益。默认继续使用 Task/Task<T>，只有性能测量确认分配是问题、同步完成比例足够高，而且 API 使用约束能够被接受时，再设计返回 ValueTask 的接口。

LongRunning 是调度提示，不是异步方案

TaskCreationOptions.LongRunning 用于告诉任务调度器：这项工作可能长时间运行，额外线程可能是合理的。默认调度器通常会为它使用线程池之外的线程，避免长期占住线程池的全局或本地队列。

它仍然只是提供给调度器的提示，不是强制所有自定义调度器采用同一种实现，也不会让同步 I/O 变成异步 I/O。尤其不要把异步委托随意交给 Task.Factory.StartNew(..., LongRunning)：委托运行到第一个未完成的 await 就会返回内部 Task，专用线程并不会因此负责整个异步操作。

对于 ASP.NET Core 中可持续运行的后台处理，生命周期、异常、取消和并发控制通常应由 BackgroundService 与有界队列负责，而不是为每一项工作创建 LongRunning Task。

🔬 观察线程复用与工作排队

下面的控制台代码向线程池提交 12 个工作项，并记录执行它们的线程 ID：

using System.Collections.Concurrent;

var threadIds = new ConcurrentDictionary<int, byte>();
using var completed = new CountdownEvent(12);

for (var i = 0; i < 12; i++)
{
    var workItem = i;
    ThreadPool.QueueUserWorkItem(_ =>
    {
        var threadId = Environment.CurrentManagedThreadId;
        threadIds.TryAdd(threadId, 0);
        Console.WriteLine($"工作项 {workItem,2} -> 线程 {threadId}");

        // 仅用于让排队和线程复用更容易观察，不是生产建议。
        Thread.Sleep(100);
        completed.Signal();
    });
}

completed.Wait();

ThreadPool.GetMinThreads(out var minWorkers, out _);
ThreadPool.GetAvailableThreads(out var availableWorkers, out _);

Console.WriteLine($"观察到的线程数：{threadIds.Count}");
Console.WriteLine($"线程池当前线程数：{ThreadPool.ThreadCount}");
Console.WriteLine($"最小工作线程数：{minWorkers}");
Console.WriteLine($"当前可用工作线程数：{availableWorkers}");

实际线程 ID、执行顺序和线程数量会受到处理器数量、其他线程池工作、运行时状态及调试器影响。这个实验应观察的是抽象关系：工作项由线程池线程领取，线程执行完成后可以继续处理其他工作，二者没有固定的一一对应关系。在核心数较多的机器上，这 12 个短暂阻塞的工作项可能恰好分别使用 12 个线程；这不代表后续工作会永久绑定到这些线程。

几个指标也不能按字面误读：

ThreadPool.ThreadCount 是当前线程池线程数量，不是正在执行这段业务代码的线程数量。
GetMinThreads 返回的最小值不是进程启动时预先创建的线程数。需求较低时，实际线程数可以低于它；出现需求时，它会影响线程池增加线程的方式。
GetAvailableThreads 返回的是一个瞬时容量值，大致可以理解为最大允许数量减去当前活动数量，不代表此刻有这么多已经创建并空闲等待的线程。

通常应优先使用 Task 和更高层的并行 API，而不是直接调用 QueueUserWorkItem。后者在这里主要用于把“工作项进入线程池”这件事显示出来。

📈 线程池为什么不立即创建大量线程

当工作进入队列但现有线程无法及时处理时，最直接的想法是立刻创建足够多的线程。然而线程过多会增加栈内存、上下文切换、锁竞争和缓存失效，还可能把压力快速传递给数据库、缓存或第三方接口。

线程池需要在两种风险之间取舍：

线程太少，处理器或外部资源没有得到充分利用，工作在队列中等待。
线程太多，调度和竞争成本上升，单位时间内完成的工作反而减少。

.NET 运行时会根据工作完成情况动态调整线程数量，目标是提高单位时间内的完成量。Hill Climbing 是这个动态调节过程中的重要机制，可以把它理解为：运行时不断观察线程数量变化对吞吐量的影响，再逐步寻找更合适的并发度。业务代码不需要也不应该依赖它的具体采样周期或内部参数。

运行时通过反馈不断探测更合适的线程数量，目标是吞吐量，而不是线程越多越好。

最小线程数不是预热线程数

线程池包含最小值与最大值配置，但最小线程数并不表示运行时会在启动时创建同样数量的线程。出现工作需求时，线程池可以较快地增加线程；超过相应阈值后，扩容会更加谨慎，并继续根据吞吐量和阻塞情况调整。

从 .NET 6 开始，线程池对 Task.Wait、Task<T>.Result 等部分可识别的阻塞模式能够更快地增加线程。在 .NET 10 中仍然可以受益于这些改进，但这只是缩短某些饥饿阶段，并没有把同步阻塞变成无成本操作。被阻塞的线程仍然占用内存和调度资源，负载变化时仍可能出现明显延迟。

🚨 什么是线程池饥饿

线程池饥饿是指线程池没有足够的可用线程处理新工作，导致工作持续排队、应用响应变慢的状态。常见原因是很多线程池线程正在同步等待：

调用 Thread.Sleep。
使用 .Result、.Wait() 或 GetAwaiter().GetResult() 同步等待异步操作。
长时间持有或等待锁。
等待同步 I/O、信号量或其他等待句柄。
在线程池中执行大量没有并发边界的长时间工作。

饥饿的关键不是“线程数已经达到最大值”，而是现有线程无法及时回到池中处理排队工作。运行时通常会尝试增加线程补偿，因此实际现象经常是线程数逐步上升，而不是固定不动。

它与相邻问题有什么区别

状态	典型表现	核心问题
正常排队	队列短暂升高后回落，延迟保持在目标范围	瞬时负载高于处理速度，但系统能及时恢复
线程池饥饿	队列或延迟持续升高，线程数继续增长，CPU 可能不高	工作线程被阻塞或占用，缺少线程处理新工作
CPU 饱和	CPU 长时间接近上限，增加线程通常不能改善吞吐量	计算需求已经接近处理器能力
锁竞争	大量线程等待同一把锁，吞吐量随竞争加剧而下降	共享临界区限制并发
死锁	相关执行路径互相等待，特定工作无法继续	等待关系形成无法自行解除的环

这些问题可能同时出现。例如锁竞争既会阻塞线程，也可能进一步造成线程池饥饿。因此诊断不能只看某一个指标。

⏳ 阻塞线程与异步等待

下面两段代码都在大约一秒后返回，但对线程池的影响不同：

static string BlockingWait()
{
    Thread.Sleep(1_000); // 实验中的反例：当前线程被占用
    return "done";
}

static async Task<string> AsyncWaitAsync()
{
    await Task.Delay(1_000); // 等待期间不持续占用工作线程
    return "done";
}

Thread.Sleep 会让当前线程在一秒内无法处理其他工作。Task.Delay 则注册计时并返回未完成的 Task；等待期间不需要保留一个线程停在那里。计时完成后，运行时再调度后续代码。

这里使用 Task.Delay 是为了清晰展示异步等待，并不表示网络、数据库或文件 I/O 在内部通过 Task.Delay 实现。生产代码应调用这些组件真正提供的异步 API，例如 ReadAsync、SendAsync 或 ExecuteReaderAsync。

🌐 ASP.NET Core 中的饥饿是怎样形成的

ASP.NET Core 会大量使用线程池处理请求代码。下面三个最小 API 表面上都在一秒左右返回，但并发负载下的资源模型完全不同：

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// 反例：直接阻塞处理当前请求的线程。
app.MapGet("/blocking", () =>
{
    Thread.Sleep(1_000);
    return Results.Ok("done");
});

// 反例：把异步操作同步等待，形成 sync-over-async。
app.MapGet("/sync-over-async", () =>
{
    var result = SimulateIoAsync().Result;
    return Results.Ok(result);
});

// 推荐：让异步调用链保持异步。
app.MapGet("/async", async () =>
{
    var result = await SimulateIoAsync();
    return Results.Ok(result);
});

app.Run();

static async Task<string> SimulateIoAsync()
{
    await Task.Delay(1_000);
    return "done";
}

/blocking 在整个等待期间占用请求线程。/sync-over-async 虽然调用了异步方法，却马上通过 .Result 阻塞当前线程，异步操作完成后的延续代码还需要线程池线程执行。调用方占着线程等待，完成方又需要线程，这正是 sync-over-async 容易放大饥饿的原因。

ASP.NET Core 默认没有传统 ASP.NET 的请求 SynchronizationContext，因此这里不一定出现经典的上下文死锁，但线程仍然被阻塞。没有死锁不代表没有线程池饥饿。

请求增加后，大量同步阻塞会占住工作线程，新工作开始排队，运行时只能逐步增加线程补偿。扩容期间延迟和资源成本都会继续上升。

线程被同步等待占用I/O 等待期间线程可复用指标为趋势示意，不代表固定阈值

/async 在等待期间把线程还给线程池，同一批线程因此能够服务更多并发请求。它没有让一秒钟的外部等待消失，而是避免为每一个等待中的请求长期占用一个线程。

📊 用 dotnet-counters 判断是否可能饥饿

dotnet-counters 适合做第一层实时观察。找到目标进程 PID 后，可以监控 System.Runtime：

dotnet-counters monitor --process-id <PID> --counters System.Runtime

.NET 10 SDK 还支持通过 dnx dotnet-counters 临时运行工具，无需永久安装。无论使用哪种启动方式，判断逻辑都相同。

与线程池直接相关的三个指标是：

指标	含义	观察重点
`dotnet.thread_pool.thread.count`	当前线程池线程数量	是否在负载下持续增加，并稳定在异常高位
`dotnet.thread_pool.queue.length`	当前等待执行的工作项数量	是否持续积压，而不是短暂升高后回落
`dotnet.thread_pool.work_item.count`	进程启动后已完成的线程池工作项累计数量	关注一段时间内的增长速度，而不是绝对值大小

线程池饥饿没有一个可以单独判定问题的神奇阈值。更可信的证据组合通常是：

请求延迟明显恶化，吞吐量下降。
线程池线程数量仍在缓慢或持续增加。
工作队列经常积压，或者工作完成速度低于进入速度。
CPU 使用率明显低于饱和状态。

队列长度不一定始终很大。线程池补偿到足够高的线程数后，队列可能回落，应用也可能暂时恢复吞吐量。此时“没有可用线程”的饥饿阶段可能已经结束，但大量阻塞线程和过高线程数仍说明代码存在效率问题；下一次突发流量或进程重启时，扩容阶段还可能再次出现。

🔍 从指标走向阻塞位置

计数器只能说明“线程池很可能正在补偿”，不能说明“哪一行代码阻塞了线程”。下一步需要查看调用栈或收集跟踪。

持续问题：dotnet-stack

如果问题在采集时持续存在，可以直接查看目标进程的托管线程调用栈：

dotnet-stack report --process-id <PID>

诊断时先确认栈底是否能看到线程池工作入口，再观察大量相似调用栈停在什么位置。常见信号包括：

Task<T>.Result、Task.Wait 或 GetAwaiter().GetResult()。
Monitor.Enter、lock 或其他同步锁等待。
ManualResetEventSlim.Wait、SemaphoreSlim.Wait 等同步等待。
同步网络、文件或数据库调用。

一个线程在等待并不能证明饥饿。真正有意义的是大量线程池线程出现相似阻塞栈，并且与计数器趋势和请求延迟相互印证。

间歇问题：dotnet-trace

如果阻塞只偶尔出现，现场抓取调用栈可能正好错过。此时可以在一段时间内收集等待事件：

dotnet-trace collect --process-id <PID> --clrevents waithandle --clreventlevel verbose --duration 00:00:30

.NET 9 引入的 WaitHandleWait 事件在 .NET 10 中可以帮助定位 Task.Result、Task.Wait、GetAwaiter().GetResult()、lock、Monitor.Enter、ManualResetEventSlim.Wait 和 SemaphoreSlim.Wait 等阻塞等待。分析事件时仍要筛选线程池线程；专用线程上的等待不一定与线程池饥饿有关。

工具的选择可以概括为：计数器发现趋势，调用栈定位持续阻塞，跟踪捕获间歇阻塞。它们提供的是逐层收窄证据，而不是彼此替代。

🛠️ 修复的重点是释放线程

如果根因是同步等待异步 I/O，首选修复方式是让调用链保持异步：

// 阻塞当前线程
var customer = GetCustomerAsync(id).Result;

// 等待期间释放当前线程
var customer = await GetCustomerAsync(id);

只修改最内层方法通常不够。如果上层最终又调用 .Result 或 .Wait()，阻塞仍然存在。异步应该沿调用链传播到 Controller、Minimal API 端点、消息处理器或后台任务的自然边界。

修复后应在相同负载下重新观察：

队列能否及时回落。
线程数量是否更低、更稳定。
单位时间完成的工作是否增加。
平均延迟和尾延迟是否改善。
CPU 或下游服务是否成为新的瓶颈。

不要只根据“代码已经改成 async”宣布问题解决。异步 I/O 可以减少等待占用的线程，但不能提高数据库容量，也不能消除 CPU 密集型计算。

⚠️ 常见误区与调优边界

1. 用 Task.Run 包装同步 I/O

var result = await Task.Run(() => database.ExecuteSync());

这段代码可能让调用线程暂时返回，但同步 I/O 仍然占用另一个线程池线程。在桌面应用中，它有时可以避免阻塞 UI 线程；在 ASP.NET Core 服务端，它通常只是把阻塞从一个线程池线程搬到另一个线程池线程，不能提升整体可伸缩性。

Task.Run 更适合明确的 CPU 密集型工作。但 CPU 工作也不能无边界并行，否则会从线程池饥饿转向 CPU 饱和和调度竞争。

2. 直接提高最小线程数

ThreadPool.SetMinThreads 可以让线程池在突发工作到来时更积极地提供线程，因此在经过测量的特殊场景中可能缩短扩容延迟。但它不会解除任何一个被阻塞的线程，还可能让大量工作同时冲向数据库或外部服务。

只有在已经确认以下事实后，才值得评估最小线程数：

阻塞能够消除的部分已经处理。
瓶颈确实发生在负载突增时的线程池爬升阶段。
下游容量能够承受更高的瞬时并发。
修改前后使用相同负载进行了验证。

不要从其他机器复制一个固定值。处理器数量、容器限额、请求模型和下游容量不同，合理值也会不同。

3. 提高最大线程数掩盖阻塞

最大线程数通常很高，普通服务很少因为首先碰到最大值而发生饥饿。即使提高上限能让更多线程存在，也可能增加内存消耗、上下文切换和资源竞争。它无法把有问题的同步等待变成高效的异步等待。

4. 把长任务无限留在请求线程池

ASP.NET Core 请求中启动不受控制的后台工作，会让任务生命周期、异常、关闭过程和并发度都变得不可控。对于需要脱离请求执行的长任务，应使用有界队列和受控的 BackgroundService，或者交给外部消息队列与独立工作进程。

有界的意义很重要：系统必须在过载时形成背压，而不是把无限工作继续堆进内存和线程池队列。

5. 把所有慢请求都归因于线程池

线程池指标正常时，请继续检查数据库慢查询、连接池耗尽、外部服务延迟、GC、锁竞争、CPU 热点和网络问题。线程池饥饿是一种具体故障模式，不是“服务变慢”的同义词。

✅ 排查清单

遇到疑似线程池问题时，可以按以下顺序处理：

确认症状： 记录平均延迟、尾延迟、吞吐量和异常发生的负载区间。
关联指标： 同时观察 CPU、线程池线程数、队列长度和工作完成趋势。
区分问题： 判断更像 CPU 饱和、锁竞争、死锁、下游阻塞还是线程池饥饿。
定位阻塞： 持续问题抓调用栈，间歇问题收集跟踪，不根据计数器猜代码位置。
优先消除阻塞： 使用真正的异步 I/O，让异步沿调用链传播，并限制 CPU 工作和后台任务的并发度。
重新验证： 使用相同负载比较修改前后指标，确认瓶颈没有只是转移到其他资源。

总结

理解线程池的关键，不是记住默认线程数，而是理解它在优化什么：线程池通过复用线程、排队工作和动态调节并发度，努力提高单位时间内完成的工作量。

Task 是操作的抽象，不是线程；await 是异步控制流，不是线程切换指令。真正的异步 I/O 能在等待期间释放工作线程，而同步等待会让线程无法处理其他工作。大量阻塞积累后，队列、线程数量、延迟和吞吐量会共同表现出线程池饥饿的特征。

因此，诊断时要用指标确认趋势、用调用栈或跟踪找到阻塞，修复时优先释放线程。调整最小线程数只能作为经过测量的辅助措施，不能替代对阻塞根因的处理。