ThreadPool 是 .NET 中轻量高效复用线程的机制，适用于大量短时无依赖后台任务；不适用于需控制生命周期、长时间运行、有顺序依赖或需返回结果的场景，推荐优先使用 Task.Run 或 async/await。
ThreadPool 是 .NET 中轻量级、高效复用线程的机制，适合执行大量短时、无依赖的后台任务。它不适用于需要控制生命周期、长时间运行、有顺序依赖或需返回结果的场景（这些更适合 Task、BackgroundService 或手动管理 Thread）。
ThreadPool 的核心用法
最常用的是 ThreadPool.QueueUserWorkItem，把委托排队交给线程池调度：
// 无参数委托ThreadPool.QueueUserWorkItem(_ => Console.WriteLine("Hello from thread pool"));
// 带状态对象（推荐用泛型重载避免装箱）
ThreadPool.QueueUserWorkItem(state => {<br> int id = (int)state;<br> Console.WriteLine($"Task {id} running");<br>}, 123);
注意：.NET 6+ 更推荐使用 Task.Run（底层仍走 ThreadPool），语义更清晰、支持 async/await 和异常传播：
Task.Run(() => DoSomeWork());
ThreadPool 的工作原理
线程池内部维护两个队列：一个全局队列（Global Queue），多个本地队列（Local Queue，每个工作线程一个）。新任务优先入全局队列；工作线程在空闲时先尝试从本地队列取任务（减少锁竞争），本地队列空了再“偷”全局队列或其他线程的本地队列任务（Work-Stealing）。
线程数量由 ThreadPool.GetMinThreads 和 ThreadPool.GetMaxThreads 控制，默认最小值通常为 CPU 核心数，最大值默认是数百（具体取决于系统配置）。线程池会按需创建线程，但不会无限增长——如果任务持续积压，说明可能任务过长或 I/O 阻塞，应考虑异步 I/O（async/await）而非增加线程。
常见误区与调优建议
避免在 ThreadPool 线程中调用 Thread.Sleep、Task.Wait、Result 或同步 I/O（如 File.ReadAllText），这会阻塞线程，降低吞吐量。
- 用
await Task.Delay替代Thread.Sleep - 用
await File.ReadAllTextAsync替代同步读文件 - CPU 密集型小任务可继续用 ThreadPool；大计算量建议分片 +
Parallel.ForEach或Task.Run - 必要时可通过
ThreadPool.SetMinThreads预热（如高并发 Web 启动阶段），但慎用SetMaxThreads，易掩盖设计问题
ThreadPool vs Task：何时选哪个？
Task 是对 ThreadPool 的高层封装，提供取消、延续、异常聚合、结构化异步等能力。绝大多数现代 C# 场景应优先用 Task.Run 或 async/await。
直接操作 ThreadPool 的典型场景极少，例如：
- 极低延迟要求，需绕过 Task 调度开销（罕见）
- 自定义异步基元（如实现自己的
ValueTask池） - 遗留代码迁移过渡期
基本上就这些。用对方式，ThreadPool 仍是 .NET 并发基石之一，只是多数时候你已通过 Task 间接用上了它。
