线程数不应简单设为CPU核心数,需据任务类型动态计算;I/O密集型用公式“核心数×(1+阻塞时间/运行时间)”,并合理配置ThreadPoolExecutor参数、隔离线程池、监控关键指标。

线程数设成 CPU 核心数就对了吗?
不对。盲目设为 Runtime.getRuntime().availableProcessors() 是常见误区。CPU 密集型任务(如大量计算、加密)才接近这个值;I/O 密集型(如数据库查询、HTTP 调用、文件读写)需要更多线程来掩盖阻塞,否则 CPU 会长时间空转。
真正合理的线程数取决于任务类型、平均阻塞时间与平均运行时间的比值。通用估算公式是:线程数 ≈ CPU 核心数 × (1 + 平均阻塞时间 / 平均运行时间)。例如:核心数为 8,每次请求平均运行 10ms、阻塞 90ms,则理论值 ≈ 8 × (1 + 9) = 80。
- 纯计算任务(无 I/O):线程数设为
availableProcessors()或略高(如 +1),避免上下文切换开销 - 混合型任务(如 Spring Boot Web 应用):Web 容器(Tomcat)默认
maxThreads=200,但实际业务线程池应单独配置,不复用容器线程 - 数据库连接池大小 ≠ 线程池大小:比如 HikariCP 默认
maximumPoolSize=10,若线程池设 50,多数线程会卡在获取连接上,反而加剧争用
ThreadPoolExecutor 构造参数怎么配才不翻车?
直接用 Executors.newFixedThreadPool(n) 在生产环境极危险:它使用无界队列 LinkedBlockingQueue,任务持续涌入会导致 OOM。必须手动构造 ThreadPoolExecutor,控制队列容量和拒绝策略。
关键参数组合建议:
立即学习“Java免费学习笔记(深入)”;
-
corePoolSize:常驻线程数,设为预估的稳定并发量(如日均峰值 QPS × 平均处理时长秒数) -
maximumPoolSize:最大线程数,一般不超过 core × 2~3,防止突发流量打垮系统 -
workQueue:优先选有界队列,如new ArrayBlockingQueue(100);慎用SynchronousQueue(要求线程立即可用,否则直接触发拒绝) -
RejectedExecutionHandler:别用默认的AbortPolicy(抛RejectedExecutionException)。推荐CallerRunsPolicy(让提交线程自己执行任务,自然降速)或自定义记录告警
ThreadPoolExecutor executor = new ThreadPoolExecutor(
8, // corePoolSize
16, // maximumPoolSize
60L, // keepAliveTime
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100),
new ThreadFactoryBuilder().setNameFormat("biz-task-%d").build(),
new ThreadPoolExecutor.CallerRunsPolicy()
);
如何验证线程数是否合理?
不能只看吞吐量(TPS)——它可能在错误配置下暂时“好看”。重点观察三类指标:
- CPU 使用率:长期 > 90% 且线程数已到
maximumPoolSize,说明计算资源饱和,需优化代码或扩容 - 线程池队列长度:持续增长 → 任务消费不过来,要么线程太少,要么单任务太慢(查 DB、远程调用未加超时)
- GC 频率与 Full GC 次数:线程过多导致对象创建激增,或队列堆积大量待处理任务对象,引发内存压力
用 JMX 或 Arthas 实时查看:ThreadPoolExecutor.getQueue().size()、getActiveCount()、getCompletedTaskCount()。压测时逐步提高并发,观察响应时间拐点(如 P95 从 50ms 突增至 500ms),该点附近的线程数就是临界值。
异步任务要不要共用同一个线程池?
不要。不同优先级、不同耗时、不同错误影响范围的任务混用线程池,会导致雪崩传导。例如:发短信(低频、可容忍延迟)和库存扣减(高频、强一致性)共用一个池,前者因运营商接口抖动而积压,会拖垮后者。
按业务维度隔离:
- RPC 调用:单独池,配合熔断(如 Sentinel)
- 定时任务:用
ScheduledThreadPoolExecutor,避免和业务线程池抢占 - 日志异步刷盘:极轻量,可用单线程池(
Executors.newSingleThreadExecutor()) - 消息发送(如 Kafka 生产者回调):必须独立,防止网络问题阻塞主业务流
命名和监控也要区分——所有线程工厂必须设 setNameFormat,否则线程 dump 里全是 pool-1-thread-1,根本分不清谁干了什么。











