线程池参数需与CPU、内存、句柄及下游承载力动态平衡：CPU密集型设corePoolSize为CPU核数+1，I/O密集型为核数×2～4；workQueue优先选有界队列并按内存与峰值估算容量；maximumPoolSize受JVM线程上限及下游连接数约束；keepAliveTime推荐I/O型60秒、计算型10～30秒；拒绝策略应具备可观测性与可干预性。
线程池参数不能脱离系统资源独立设置。核心思路是：让线程数、队列容量和空闲策略与 CPU、内存、句柄、下游服务承载力形成动态平衡，避免“线程跑满但 CPU 闲置”或“任务堆积却不敢扩容”这类错配。
根据 CPU 利用率决定核心线程数
corePoolSize 不是固定公式，而是资源瓶颈的映射：
- CPU 密集型任务（如加解密、数值计算）：线程数过多会导致频繁上下文切换，实际吞吐反而下降。建议设为 CPU 核心数 + 1（Runtime.getRuntime().availableProcessors() + 1），保证每个核心有 1 个活跃线程，+1 用于补偿 GC 或系统调度抖动。
- I/O 密集型任务（如 HTTP 调用、数据库查询）：线程大部分时间处于 WAITING/TIMED_WAITING 状态。此时 CPU 并未饱和，可适当提高并发度。常见范围是 CPU 核心数 × 2～4，但上限要受制于连接数、文件句柄、下游限流等——比如调用一个限流 50 QPS 的接口，即使你开了 200 个线程也无意义，还可能触发对方熔断。
- 混合型任务：观察 JVM 线程状态分布（jstack 或 Arthas thread -state）。若 WAITING 线程占比长期 >60%，说明 I/O 阻塞明显，可逐步上调 corePoolSize；若 RUNNABLE 占比高且 CPU 使用率持续 >80%，则应优先优化单任务耗时，而非盲目加线程。
队列容量必须匹配内存与业务峰值
workQueue 不是“缓冲兜底”，而是资源压力的转移点：
- ArrayBlockingQueue（有界）：推荐生产首选。容量需结合单任务对象大小 + 峰值持续时间估算。例如：平均任务对象占 1MB 堆内存，预计峰值持续 2 分钟、每秒进 50 个任务 → 队列至少需容纳 6000 个任务 → 至少预留 6GB 堆空间。实际应留 20% 余量，并配合监控告警（如队列使用率 >80% 触发扩容或降级）。
- LinkedBlockingQueue（无界）：默认 Integer.MAX_VALUE，等于放弃背压控制。一旦任务提交速率 > 执行速率，堆内存持续增长，GC 频繁，最终 OOM。仅适合极低风险、可严格控速的内部批处理场景。
- SynchronousQueue（无缓冲）：不排队，强制“有空闲线程就执行，否则立刻扩容”。适用于响应敏感型服务（如网关转发），但要求 maximumPoolSize 设置合理，否则容易因扩容失败触发拒绝策略。
keepAliveTime 和 maximumPoolSize 要协同看下游承载力
这两个参数共同决定“弹性伸缩”的实际效果：
立即学习“Java免费学习笔记（深入）”；
- maximumPoolSize 不是越大越好。它受限于：JVM 可创建线程数（受 -Xss 和系统 ulimit -u 限制）、堆外内存（每个线程约占用 1MB 栈空间）、数据库连接池最大连接数、第三方 API 的并发调用配额。例如 MySQL 连接池 maxActive=50，那线程池再大也无法并行执行超过 50 个 DB 查询。
- keepAliveTime 只对 > corePoolSize 的线程生效。设太短（如 100ms）会导致高峰过后线程反复销毁重建，增加 native thread 创建开销；设太长（如 30 分钟）则低峰期仍占大量内存和句柄。推荐值：I/O 型任务设 60 秒，兼顾复用与释放；计算型任务设 10～30 秒；若启用 allowCoreThreadTimeOut(true)，所有线程都受此约束，此时统一设 60 秒更稳妥。
拒绝策略是资源过载的信号，不是兜底方案
handler 的选择反映你对资源瓶颈的预判和应对能力：
- AbortPolicy（默认）：适合需要快速暴露问题的场景（如定时任务调度器），但线上服务慎用——异常抛给上游可能引发雪崩。
- CallerRunsPolicy：让提交线程自己执行，相当于把压力反压回上游。适合轻量、幂等任务，能自然限流，但要注意调用方线程是否允许阻塞。
- 自定义策略：更推荐。例如记录被拒任务 ID + 上游 IP + 时间戳，触发告警；或写入本地磁盘队列异步重试；或直接返回降级响应（如缓存数据、默认值）。关键是要把“拒绝”变成可观测、可追溯、可干预的动作。
