线程池是按需唤醒、空闲回收、自动伸缩的资源池，性能问题多源于任务写法不当；threadpool.queueuserworkitem 捕获循环变量引用导致所有任务读取终值，应声明局部副本；后台线程特性决定不可用于需优雅关闭、sta com、长阻塞等任务；setmin/maxthreads 多数无需手动调整，clr 自带饥饿避免算法。
线程池不是“启动后一直活着”的线程集合，而是按需唤醒、空闲回收、自动伸缩的资源池；绝大多数性能问题不来自线程池本身，而来自任务写法不当或误用场景。
ThreadPool.QueueUserWorkItem 为什么总拿到循环变量的最终值？
这是最常被当成“线程池 bug”的现象：在 for 循环里反复调用 ThreadPool.QueueUserWorkItem，结果所有任务都看到同一个变量值（比如 i == 5）。
根本原因不是线程池，是 lambda 捕获了变量 i 的引用，而非它某次迭代的值。循环结束时 i 已是终值，所有任务执行时读的都是这个终值。
- 修复方式：在循环体内声明局部副本，比如
int taskNumber = i;，然后在 lambda 中使用taskNumber -
QueueUserWorkItem接收的是WaitCallback委托，签名固定为void Method(object state)，传入的state必须是object类型——值类型会装箱，但合法 - 不要试图靠
Thread.Sleep或顺序提交来“等”变量稳定，这既不可靠也不可扩展
哪些任务绝对不能塞进 ThreadPool？
线程池线程是后台线程（IsBackground == true），进程退出时直接终止，不等待你收尾。以下几类任务一旦塞进去，轻则资源泄漏，重则数据损坏：
- 带
while(true) + Thread.Sleep的轮询逻辑——程序关掉就断，可能留文件句柄、DB 连接未释放 - 需要优雅关闭的监听器（如消息队列消费者、定时器回调）
- 依赖 STA 线程的 COM 对象（如旧版 Office 自动化），线程池全是 MTA
- 同步 I/O 或长阻塞操作（如
File.ReadAllBytes大文件、Thread.Sleep(5000)）——会“卡住”线程池线程，拖慢其他任务
这类需求请改用 Task.Run 配合 CancellationToken，或 ASP.NET Core 下的 IHostedService。
ThreadPool.SetMinThreads 和 SetMaxThreads 到底要不要调？
绝大多数情况不需要手动调。CLR 的线程池自带饥饿避免算法（Hill Climbing），能根据负载动态扩缩。乱调反而容易引发新问题：
-
SetMinThreads过高：空闲线程长期驻留，浪费内存和调度开销 -
SetMaxThreads过低：任务排队堆积，响应延迟突增；过高则上下文切换频繁，CPU 反而跑不满 - 默认最小线程数 ≈ CPU 核心数，最大线程数通常几百到上千（.NET 版本和系统有关），已覆盖多数短期任务场景
- 只有在明确观测到线程池“起不来”（如高并发冷启动时大量任务排队超 1 秒），且排除了任务阻塞后，才考虑微调
MinThreads
真正难处理的，从来不是怎么“塞任务”，而是怎么让任务不阻塞、不捕获错误变量、不赖在线程池里不走——这些细节藏在业务逻辑里，不在 ThreadPool 的 API 表面。
