线程池参数需依据CPU核心数、内存和IO能力科学配置：CPU密集型设为cpuCount+1，IO密集型为cpuCount×2～4，队列必须有界并配明确拒绝策略，上线后通过活跃线程数、队列长度和GC指标持续验证。
线程池参数不能脱离服务器硬件拍脑袋填，必须和 CPU 核心数、内存容量、IO 能力对齐。核心思路是：先算出理论线程数基线，再结合任务类型缩放，最后用有界队列+明确拒绝策略守住底线。
第一步：获取真实 CPU 核心数并区分任务类型
别直接写死数字，用运行时获取：
int cpuCount = Runtime.getRuntime().availableProcessors();
拿到这个值后，立刻判断业务任务性质：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型（如加解密、实时渲染、风控规则计算）：线程数 ≈ cpuCount + 1。多这 1 个是为了防止单个线程因缺页或锁等待暂停时，CPU 空转。
- I/O 密集型（如 HTTP 调用、DB 查询、Redis 操作）：线程数可设为 cpuCount × 2～4。若能估算单任务平均等待时间（W）与计算时间（C），用公式 cpuCount × (1 + W/C) 更准；不确定就从 2 倍起步，压测后再调。
- 混合型：优先拆分——把纯计算部分交给小线程池（cpuCount+1），I/O 部分交给大线程池（cpuCount×3）。不拆就取中间值，比如 cpuCount×2.5，并重点监控 GC 和响应延迟。
第二步：队列必须有界，容量要匹配吞吐预期
无界队列（如 new LinkedBlockingQueue()）是线上事故高发区，它会让任务全堆进堆内存，最终触发 OOM。正确做法是：
- 选 ArrayBlockingQueue 或带容量的 LinkedBlockingQueue(capacity)，容量值不是越大越好。
- 队列长度建议设为：核心线程数 × 期望平均排队时长（秒）× QPS。例如：核心线程 8，QPS 200，允许平均排队 0.2 秒 → 队列大小 ≈ 8 × 200 × 0.2 = 320，取整设为 300 或 500 即可。
- 如果业务对响应时间极其敏感（如网关、支付回调），可考虑 SynchronousQueue，它不存任务，提交即创建线程或触发拒绝，逼系统快速失败而非沉默堆积。
第三步：线程数上下限要联动，拒绝策略必须显式指定
corePoolSize 和 maximumPoolSize 不建议拉开过大差距。常见误区是设成 10/200 这种组合，结果流量一冲，线程数飙到 200，上下文切换吃光 CPU。
- 推荐方案一（稳态服务）：两者设为相同值，如 core=16, max=16，配 ArrayBlockingQueue(200)，拒绝策略用 CallerRunsPolicy。这样任务超载时，由调用方线程自己执行一个任务，自然降速，保护后端不雪崩。
- 推荐方案二（流量波动大）：core 设为稳态所需值（如 12），max 可略高（如 24），但 keepAliveTime 要设短（如 30 秒），确保空闲线程快速回收。队列仍需有界（如 100），拒绝策略选 AbortPolicy 或自定义日志告警策略，让问题暴露得早。
- 绝对避免 Executors.newCachedThreadPool() —— 它的 max 是 Integer.MAX_VALUE，无队列，看似弹性实则失控；也别用 newFixedThreadPool(n)，它底层用的是无界 LinkedBlockingQueue，隐患一样大。
第四步：上线后靠指标验证，不是靠感觉
配置完只是开始，必须持续看这几个关键指标：
- executor.getActiveCount()：长期接近 corePoolSize 说明资源有余；频繁顶到 maximumPoolSize，说明线程不够或任务太慢。
- executor.getQueue().size()：持续 > 队列容量 70%，说明处理不过来，要么升线程、要么优化单任务耗时、要么调整队列容量。
- GC 日志中老年代使用率 & FGC 频次：如果队列积压导致对象长期存活，老年代会快速涨满，FGC 频繁就是内存被任务对象撑爆的信号。
- 配合监控埋点，把活跃线程数、队列长度、拒绝数做成仪表盘，设置阈值告警，比等用户投诉再查 dump 强十倍。
