线程数不应简单设为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免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
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，根本分不清谁干了什么。
