ThreadPoolExecutor七大参数协同决定线程池行为：corePoolSize设常驻线程下限，maximumPoolSize为上限，keepAliveTime控制临时线程超时，workQueue类型影响扩容与排队策略，threadFactory定制线程创建，handler处理拒绝任务，allowCoreThreadTimeOut控制core线程是否可回收。
ThreadPoolExecutor 的七大核心参数决定了线程池的行为边界与资源调度逻辑，合理配置能兼顾性能、稳定性与资源利用率。关键不是堆高数字，而是理解每个参数的职责及其相互制约关系。
corePoolSize：常驻线程的“底线”
这是线程池中始终存活的最小线程数，即使空闲也不会被回收（除非 allowCoreThreadTimeOut = true）。它决定了任务低峰期的响应能力。
- 设得太小（如 1）：并发稍高就排队或新建线程，响应延迟明显
- 设得太大（如远超 CPU 核数）：空闲线程占用内存和上下文切换开销，反而降低吞吐
- 建议值：CPU 密集型任务 ≈ CPU 核数；IO 密集型可适当放大（如 ×2～×4），需结合压测验证
maximumPoolSize：线程数量的“天花板”
当任务持续涌入、队列已满时，线程池最多可扩容到该数量。它和 corePoolSize 共同定义了线程的弹性范围。
- 如果使用无界队列（如 LinkedBlockingQueue），maximumPoolSize 实际无效——因为永远不会触发扩容
- 若用有界队列（如 ArrayBlockingQueue），该值才真正起作用，防止无限创建线程导致 OOM
- 不建议设为 Integer.MAX_VALUE，应结合系统内存、句柄数、业务最大并发预期来保守设定
keepAliveTime & unit：空闲线程的“生存倒计时”
超出 corePoolSize 的线程，在空闲超过 keepAliveTime 后会被终止。unit 是其时间单位（如 TimeUnit.SECONDS）。
- 仅对 > corePoolSize 的“临时线程”生效；core 线程默认永驻
- 设为 0 表示空闲即销毁（但要注意：JDK 8+ 对 0 值有特殊处理，可能立即回收，慎用）
- 常见设置：60 秒、30 秒，平衡资源释放及时性与线程复用成本
workQueue：任务的“缓冲区”与行为分水岭
存放等待执行的 Runnable。它的类型直接决定线程池是“优先扩容”还是“优先排队”。
- SynchronousQueue：无容量，插入即要求有空闲线程，否则触发扩容 → 适合任务突发、希望快速响应的场景
- ArrayBlockingQueue：有界队列，满后触发扩容 → 可控内存占用，推荐用于生产环境
- LinkedBlockingQueue：默认无界（Integer.MAX_VALUE），易掩盖问题 → 高并发下可能 OOM，不建议直接用默认构造
- PriorityBlockingQueue：支持优先级排序，但注意：它不保证公平性，且扩容逻辑仍依赖 maximumPoolSize
threadFactory：线程的“出生证明”
用于创建新线程，默认使用 Executors.defaultThreadFactory()。自定义可统一命名、设守护线程、加 UncaughtExceptionHandler。
- 命名规范很重要：比如命名为 “order-processor-pool-%d”，便于排查线程归属
- 建议设置 setUncaughtExceptionHandler，避免异常静默丢失
- 避免在 factory 中做耗时操作（如远程调用），否则会拖慢 submit 速度
handler：队列满 + 线程达上限时的“兜底策略”
拒绝策略决定如何应对无法接纳的新任务。JDK 提供四种内置实现，也可自定义：
- AbortPolicy（默认）：抛 RejectedExecutionException，最严格，适合不允许丢任务的场景
- CallerRunsPolicy：由提交任务的线程自己执行该任务 → 降低提交速率，起到反压作用
- DiscardPolicy：静默丢弃，适合允许丢失的非关键任务（如日志上报）
- DiscardOldestPolicy：丢弃队列头任务，再尝试提交当前任务 → 有一定“保鲜”效果，但可能丢旧任务
allowCoreThreadTimeOut：给 core 线程加个“休眠开关”
默认 false，即 core 线程永不超时。设为 true 后，所有线程（包括 core）空闲超时都会被回收。
- 开启后，线程池可彻底缩容至 0，适合流量波动极大、长周期空闲的后台服务
- 注意副作用：下次任务来临时需重新创建线程，有短暂延迟；不适合对首次响应要求极高的场景
- 必须配合非零 keepAliveTime 才有意义
这七个参数不是孤立配置的，而是一套联动机制：workQueue 类型影响是否触发 maximumPoolSize；keepAliveTime 和 allowCoreThreadTimeOut 共同控制生命周期；handler 是前序策略失效后的最后防线。实际配置时，先明确业务模型（CPU/IO 密集？流量是否突增？任务是否可丢？），再结合监控数据迭代调优，比套用模板更可靠。
