线程池

应用变慢时，第一反应很容易是“线程不够”或“CPU 不够”。但在高并发 Web 应用中，更常见的情况是线程池线程都被阻塞了：线程数量不断增加，工作项排队等待，新的请求迟迟得不到执行。 这就是线程池饥饿（Thread Pool Starvation）。本文用一次 SQLite 相关的现场问题说明如何观察它，以及为什么简单增加线程数往往会让问题更糟。 什么是线程池饥饿 当线程池没有可用线程处理新的工作项时，就发生了线程池饥饿。应用通常表现为响应变慢、请求超时，但 CPU 利用率未必很高。 常见诱因包括： 在异步方法上调用 .Result 或 .Wait()； 使用 Thread.Sleep； 长时间运行的定时任务或后台任务占用线程池线程； 同步阻塞 I/O； 多个线程竞争同一把锁； 数据库调用长时间等待锁释放。 尤其要注意，业务代码不需要“完全同步”才会产生饥饿。只要异步链路中夹杂了阻塞调用，线程池就可能在压力下逐渐耗尽可用线程。 用 dotnet-counters 观察现场 先对目标进程做压测，同时运行： dotnet-counters monitor -p 12256 重点观察 [System.Runtime] 下的几个指标： ThreadPool Queue Length 75 ThreadPool Thread Count 38 ThreadPool Completed Work Item Count 128 / sec 如果 ThreadPool Queue Length 持续增长，说明工作项已经开始排队；如果 ThreadPool Thread Count 长时间明显高于 CPU 核心数，同时队列仍然无法消化，这是线程池饥饿的强烈信号。现场案例中线程数长期达到 CPU 核心数约 3 倍，仍有大量工作项等待。 这个判断应该结合趋势和请求延迟一起看，不能把“线程数超过核心数”单独当成故障证明。线程池在遇到阻塞时主动注入线程本身就是一种正常的补救机制，问题在于注入的线程也被同样的阻塞点卡住了。 用 dotnet-stack 看谁在阻塞 线上通常无法附加 debugger，这时可以使用 dotnet-stack 获取托管线程的调用栈。现场看到的一类关键栈如下： ...