C# .NET4.8 ThreadPool工作线程数远低于预期问题排查

首先直接回答你的两个核心疑问：

• 在线程池工作线程内调用ThreadPool.GetMaxThreads、ThreadPool.GetAvailableThreads返回值是完全准确的，不存在调用上下文导致数值不准的问题。
• .NET Framework 4.8 线程池确实自带动态增减、回收空闲线程的机制，不会一直维持高线程数，但你观测到的低并行、低线程占用现象，核心原因是你对Timer调度逻辑的认知错误，以及现有任务调度代码的天生缺陷，和线程池本身的统计API无关。

你对System.Threading.Timer的初始认知完全错误 #

你最开始认为Timer会每隔固定时间启动新线程触发回调，这个理解是错的：
System.Threading.Timer的回调永远是投递到线程池工作队列执行，从来不会主动创建新线程：

• 如果上一次回调还没执行完，到了设定的触发间隔，新的回调只会在线程池队列里排队，不会强制并行执行
• 你贴出的完整代码里，Timer的实际触发间隔是10（也就是10毫秒），不是你最开始说的10000（10秒），但哪怕触发间隔再短，也不会自动提升任务处理的并行度。

现有任务调度逻辑天生把并行度压得极低 #

看DoTask方法的核心逻辑：

if (task == null)
{
    Log.DebugFormat("DoTask: Idle in thread {0} ({1} tasks running)", mtid, _processingTaskLock);
    return false;
}
System.Threading.Tasks.Task.Factory.StartNew(ProcessTask, task).ContinueWith(c => DoTask());
return true;

这段逻辑的问题非常直接：

1. 每次Timer回调进入DoTask，最多只会取出1个任务投递执行，之后当前调用链直接返回，不会继续拉取队列里的其他任务。
2. 后续的任务拉取完全依赖上一个任务执行完成后触发的ContinueWith回调，也就是说整个调度逻辑里，同一时间最多只有1个“拉取任务投递执行”的生产者在跑，根本不会出现多个线程并行抢队列任务的情况。
3. 如果单个ProcessTask执行速度很快，ContinueWith回调大概率会直接复用刚执行完上一个任务的线程池线程，根本不会触发线程池创建新线程，这就是你观测到同一时间并行任务数从来没超过2个、在用线程数不超过4个的直接原因。
4. 你拉取任务的逻辑包在DbExtensions.WithDbWrite的数据库写上下文里，数据库写锁、事务串行化的限制会进一步压低并行拉取的可能性，哪怕你手动开多线程拉任务，也会被数据库锁卡成串行。

你观测到的线程数变化完全符合.NET Framework 4.8线程池的默认行为 #

你看到的20分钟内累计出现50个不同ManagedThreadId、但同一时间活跃线程数极低的现象，完全是线程池默认调度逻辑的正常表现：

• .NET Framework 4.8线程池的默认最小工作线程数和CPU核心数挂钩，16vCPU的机器默认最小工作线程数就在16左右，但线程池注入新线程有非常保守的节流策略：当工作队列出现积压时，线程池会先等待约500毫秒，如果等待后仍然有积压请求，才会创建1个新工作线程。
• 你的场景里单个任务执行速度极快，上一个任务刚执行完，ContinueWith就立刻投递下一个任务，直接复用刚空闲的线程就能处理，任务队列根本不会出现持续积压，自然不会触发新线程创建。
• 线程池会自动回收空闲超过20秒左右的工作线程，把活跃线程数维持在最小线程数附近，所以你看到同一时间的在用线程数一直很低。
• 累计出现50个不同线程ID，是因为偶尔出现任务执行稍慢、线程临时被GC或其他系统操作占用、Timer回调排队触发线程池临时创建少量新线程，这些线程处理完任务空闲后又被回收，不会一直保留。
• 你最开始估算“10秒触发一次应该有100个线程参与工作”的逻辑完全不成立：Timer回调本身就是复用线程池线程执行，如果回调执行速度快，根本不会产生新的线程ID，自然不会有你预期的线程数量。

快速验证方法 #

你可以做两个简单测试立刻验证上述结论：

1. 在ProcessTask方法开头加Thread.Sleep(1000)，让每个任务至少执行1秒，再跑10000个任务的测试，你会看到线程数会逐步爬升，并行度明显上升。
2. 程序启动时调用ThreadPool.SetMinThreads(100, 100)把线程池最小工作线程数设到100，你会看到程序启动初期的并行度会明显高于之前，不会卡在2-4个线程的水平。

内容的提问来源于stack exchange，提问作者Jack-of-some