




线程数不应简单设为CPU核心数,需据任务类型动态计算;I/O密集型用公式“核心数×(1+阻塞时间/运行时间)”,并合理配置ThreadPoolExecutor参数、隔离线程池、监控关键指标。
不对。盲目设为 Runtime.getRuntime().availableProcessors() 是常见误区。CPU 密集型任务(如大量计算、加密)才接近这个值;I/O 密集型(如数据库查询、HTTP 调用、文件读写)需要更多线程来掩盖阻塞,否则 CPU 会长时间空转。
真正合理的线程数取决于任务类型、平均阻塞时间与平均运行时间的比值。通用估算公式是:线程数 ≈ CPU 核心数 × (1 + 平均阻塞时间 / 平均运行时间)。例如:核心数为 8,每次请求平均运行 10ms、阻塞 90ms,则理论值 ≈ 8 × (1 + 9) = 80。
availableProcessors() 或略高(如 +1),避免上下文切换开销maxThreads=200,但实际业务线程池应单独配置,不复用容器线程maximumPoolSize=10,若线程池设 50,多数线程会卡在获取连接上,反而加剧争用
直接用 Executors.newFixedThreadPool(n) 在生产环境极危险:它使用无界队列 LinkedBlockingQueue,任务持续涌入会导致 OOM。必须手动构造 ThreadPoolExecutor,控制队列容量和拒绝策略。
关键参数组合建议:
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)——它可能在错误配置下暂时“好看”。重点观察三类指标:
maximumPoolSize,说明计算资源饱和,需优化代码或扩容用 JMX 或 Arthas 实时查看:ThreadPoolExecutor.getQueue().size()、getActiveCount()、getCompletedTaskCount()。压测时逐步提高并发,观察响应时间拐点(如 P95 从 50ms 突增至 500ms),该点附近的线程数就是临界值。
不要。不同优先级、不同耗时、不同错误影响范围的任务混用线程池,会导致雪崩传导。例如:发短信(低频、可容忍延迟)和库存扣减(高频、强一致性)共用一个池,前者因运营商接口抖动而积压,会拖垮后者。
按业务维度隔离:
ScheduledThreadPoolExecutor,避免和业务线程池抢占Executors.newSingleThreadExecutor())命名和监控也要区分——所有线程工厂必须设 setNameFormat,否则线程 dump 里全是 pool-1-thread-1,根本分不清谁干了什么。