线程池参数需按任务类型区分：cpu密集型设core=核数+1、有界队列、callerrunspolicy；io密集型设core=核数×2～3、较大linkedblockingqueue、abortpolicy；混合任务应物理拆分，避免妥协配置。
Java线程池参数设置不能一概而论，关键看任务在忙什么：是让CPU持续满负荷计算，还是大部分时间在等网络、磁盘或数据库响应。不同任务类型对线程数、队列和拒绝策略的要求差异明显，配错一个参数，其他再合理也难起效。
CPU密集型任务：少而精，避免切换开销
这类任务几乎不等IO，比如加解密、图像压缩、复杂排序、科学计算。CPU长期接近100%占用，线程多了反而互相抢资源，徒增上下文切换损耗。
- corePoolSize = CPU核心数 + 1：+1是为应对GC暂停、缺页中断等短暂调度抖动，留一个备用线程保障连续性
- maximumPoolSize 通常等于 corePoolSize：不建议动态扩容，避免不确定性；keepAliveTime 可设为 0
- 队列必须有界：推荐 ArrayBlockingQueue，容量 100～1000，防任务堆积导致内存溢出
- 拒绝策略优先 CallerRunsPolicy：让提交线程自己执行，自然限流，比静默丢弃更可控
IO密集型任务：多而稳，填满CPU空闲时间
HTTP调用、DB查询、文件读写等任务，90%以上时间在等待响应，CPU实际使用率很低。多开线程能让CPU“见缝插针”处理别的请求，提升整体吞吐。
- corePoolSize = CPU核心数 × 2 ～ 3：更精准可按公式估算：CPU核数 × (1 + 平均等待时间 / 平均CPU处理时间)，但需结合压测调整
- maximumPoolSize = corePoolSize × 1.5 ～ 2：保留弹性空间应对突发流量，keepAliveTime 建议 30～60 秒
- 队列选 LinkedBlockingQueue：容量建议 2000 左右，避免无界队列引发 OOM
- 拒绝策略别用 DiscardPolicy：推荐 AbortPolicy（暴露问题）或自定义策略（如落库重试）
混合型任务：拆分优于妥协
一个接口既做AES解密（CPU型），又连三次数据库（IO型），硬凑一个线程池必然两头不讨好——CPU型任务排队饿死，IO型又因线程不足堵在连接池。
- 优先物理拆分：计算类走专用CPU池（core = 核数+1），远程调用走IO池（core = 核数×2～3）
- 调用时显式指定执行器：CompletableFuture.supplyAsync(task, executor)，不依赖默认 ForkJoinPool
- 实在无法拆分，按主责配置：若IO耗时占比超80%，就偏向IO型参数，但必须监控 getActiveCount() 和 getQueue().size()
参数配对决定真实行为
线程数只是表象，队列类型和拒绝策略才决定线程池怎么干活：
- 用 LinkedBlockingQueue 且无界 → maximumPoolSize 形同虚设，永远只启 core 个线程
- 用 SynchronousQueue → 新任务直接触发扩容，直到达 maximum，再提交就触发拒绝
- 下游瓶颈常被忽略：DB连接池最大连接数、HTTP客户端路由连接上限、网卡带宽、服务端限流值——线程再多，卡在连接池就全堵住
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
