线程池参数是系统资源、任务特性与业务风险的动态平衡点；核心线程数需按CPU/IO负载匹配，队列与拒绝策略须协同配置，最大线程数和存活时间应合理设限，运行时指标可揭示参数失配。
线程池参数不是孤立的数字，而是系统资源、任务特性与业务风险之间的动态平衡点。配置不当不会立刻报错，但会在高并发或长周期运行中逐步暴露为响应延迟、OOM、线程饥饿或任务丢失——这些表象背后，是参数之间隐性的逻辑耦合。
核心线程数与CPU/IO负载的匹配逻辑
corePoolSize 决定“常驻运力”，它必须贴合任务的实际执行特征：
- CPU密集型任务（如加解密、图像压缩）：线程过多会导致上下文切换开销反超计算收益，推荐设为 Runtime.getRuntime().availableProcessors() 或 +1
- IO密集型任务（如HTTP调用、DB查询）：线程多数时间在等待，可适度放大，常见取值为 2～4倍CPU核数，但需同步检查数据库连接池等下游瓶颈
- 混合型任务：不能靠公式拍板，需结合监控指标（如线程平均阻塞率、CPU利用率）反推合理下限
队列容量与拒绝策略构成安全阀
workQueue 和 handler 是一对协同防御组合，单独调优无效：
- 用无界队列（如默认 LinkedBlockingQueue）+ 小 corePoolSize → 任务持续堆积 → 内存缓慢泄漏直至OOM
- 用有界队列（如 ArrayBlockingQueue(100)）+ AbortPolicy → 队列满时直接抛异常 → 业务侧若未捕获，请求静默失败
- 更稳妥搭配：有界队列 + CallerRunsPolicy，让提交线程自己执行任务，天然限流并避免丢任务
最大线程数与keepAliveTime控制弹性边界
maximumPoolSize 不是“越大越好”，它是应对突发流量的缓冲带，但必须配合存活机制：
立即学习“Java免费学习笔记（深入）”；
- 设得过高（如500）→ 瞬时创建大量线程 → 触发 unable to create new native thread（OS级线程创建失败）
- keepAliveTime 过长（如30分钟）→ 非核心线程长期空闲占资源 → JVM堆外内存持续占用，GC压力上升
- 建议值：I/O型场景 keepAliveTime 设为 30～60秒，maximumPoolSize 控制在 corePoolSize 的 1.5～3 倍区间
参数联动失效的真实信号
系统稳定性下滑往往始于参数失配，注意这些运行时指标：
- getQueue().size() 持续增长 → 队列积压，说明 corePoolSize 或 maximumPoolSize 不足以消化提交速率
- getActiveCount() 长期 ≈ maximumPoolSize → 线程全忙，可能已触及系统瓶颈（CPU、DB连接、网络带宽）
- RejectedExecutionException 频发 → 不是线程池太小，而是上游提交速度远超下游处理能力，需从流量入口限流
