java线程池的七个参数协同定义其运行机制：corepoolsize设常驻线程底线，maximumpoolsize为突发流量防线，workqueue决定调度策略，keepalivetime控制非核心线程存活时长，threadfactory与handler提升可观测性与容错能力。
Java线程池不是配几个数字就完事，关键在于七个参数如何协同作用——它们共同定义了线程池的“呼吸节奏”和“应急机制”。ThreadPoolExecutor的构造器本质是一套资源调控契约，每个参数都承担明确职责，且彼此强耦合。
corePoolSize：常驻线程的底线
这是线程池默认维持的最小线程数。只要任务进来，且当前线程数未达此值，就立刻新建核心线程执行，哪怕已有空闲线程在等任务。它不因空闲而自动回收，除非显式开启allowCoreThreadTimeOut(true)。
- CPU密集型任务建议设为
Runtime.getRuntime().availableProcessors() - IO密集型可设为该值的2倍左右，具体需结合监控中CPU利用率（目标80%~90%）动态调整
- 可通过
setCorePoolSize()运行时调大或缩小；调小时，多余线程会在下次空闲时终止
maximumPoolSize：突发流量的最后防线
它不是日常水位，而是当任务队列已满、且所有核心线程都在忙时，允许创建的额外线程上限。超出此数的任务才会触发拒绝策略。
- 不能孤立设置，必须配合workQueue类型理解：用无界队列时，该值实际失效
- 经验公式参考：
corePoolSize × 2～4；更严谨可用：(QPS × 平均耗时) ÷ 可接受最大响应时间 - 调用
setMaximumPoolSize()可动态扩容，但不会立即创建新线程，只影响后续扩容行为
workQueue：任务调度的“性格开关”
队列类型直接决定线程池是“保守派”还是“激进派”。它不是单纯缓存，而是参与决策的关键一环。
- ArrayBlockingQueue（有界）：推荐生产使用。容量固定，满后触发扩容或拒绝，便于控流和压测
- SynchronousQueue（零容量）：不存任务，提交即尝试找空闲线程；找不到就建新线程（直到maximumPoolSize），适合高响应场景
- LinkedBlockingQueue（无界）：默认容量Integer.MAX_VALUE，易OOM，仅适用于低吞吐、任务极轻量且绝对可控的场景
keepAliveTime + unit：非核心线程的“保质期”
该组合只对非核心线程生效——即超过corePoolSize后创建的线程。空闲超时即销毁，避免资源长期闲置。
- 单位必须与数值严格匹配，例如
60L, TimeUnit.SECONDS，误写成毫秒会导致线程过早回收 - 若开启
allowCoreThreadTimeOut(true)，该策略也适用于核心线程 - 内部统一转为纳秒存储，所以传入时建议用
TimeUnit类方法转换，避免手工乘除出错
threadFactory 与 handler：线上可观测性与兜底能力
这两个参数常被忽略，却是故障排查和系统韧性的重要支点。
-
threadFactory：不只是起名，可统一设为守护线程、指定优先级、注入业务标识（如
"order-pool-%d"），方便JVM线程dump时快速归因 -
handler：队列满+线程数已达上限时的最终处理逻辑。默认
AbortPolicy抛异常；生产更倾向CallerRunsPolicy，让提交线程自己执行，既降速又不丢任务
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
