Java 线程池的大小、队列和拒绝策略应该怎样调优？

题型：调优 · 从任务等待、下游容量和资源预算反推参数，而不是套固定公式。

建议回答

我会先按业务和资源隔离线程池，确认任务是 CPU 密集、阻塞 I/O 还是混合型，并测量任务执行时间、等待时间、阻塞比例和下游并发上限。CPU 密集任务的并发度通常接近可用核数；I/O 任务可以更高，但最终受连接池、下游限流、内存和上下文切换约束。公式只能给初值，参数必须通过真实负载验证。

队列一般要有界，容量根据允许的排队延迟和突发流量确定。核心线程、最大线程、队列和拒绝策略是一个整体：无界队列会让最大线程数失去大部分意义，并把过载变成长尾延迟和内存问题；拒绝策略要映射成明确的降级、快速失败或调用方背压，不能静默丢任务。任务还应有超时、取消、上下文清理和可观测的名称。

如果使用虚拟线程，我会把它理解为降低“阻塞一个线程”的成本，而不是取消下游容量限制。仍要用信号量、连接池或限流器约束并发，并监控固定线程钉住、载体线程利用率和任务积压。对于 CPU 密集工作，虚拟线程不会创造额外 CPU。

关键指标

• 活跃线程、池大小、队列长度与排队时间 P95/P99。
• 任务执行时间、超时率、取消率、拒绝数和完成吞吐。
• CPU 利用率、上下文切换、内存分配与 GC 压力。
• 数据库连接池、HTTP 连接池和下游服务的饱和度与尾延迟。

关键权衡

• 增加线程可能隐藏短期排队，却会放大下游压力、上下文切换和内存占用。
• 更大队列能吸收突发，但会增加超时请求继续占资源的时间，并削弱快速失败能力。
• CallerRunsPolicy 能形成一定背压，但在事件循环、锁内或关键请求线程上可能造成级联阻塞。

易错点

• 不要只根据 CPU 核数给出固定线程数，I/O 等待、下游容量和延迟目标同样重要。
• 不要让不同 SLA、不同下游的任务共享一个无界线程池。
• 不要把虚拟线程说成不需要线程池治理或可以无限并发。