ThreadPoolExecutor七大参数是相互制约的资源调控策略：corePoolSize设常驻线程下限，maximumPoolSize为弹性上限，keepAliveTime控制非核心线程超时，workQueue决定排队或扩容倾向，threadFactory定制线程创建，handler处理拒绝任务，allowCoreThreadTimeOut控制core线程是否可回收。
ThreadPoolExecutor 的七大参数不是独立设置的数字，而是一套相互制约的资源调控策略。配置的关键在于理解它们如何协同工作，而不是孤立调大或调小某一个值。
corePoolSize：设好“常驻兵力”底线
这是线程池中始终保留的最小线程数，决定低峰期响应能力。它不等于“平均并发量”，而是任务涌入时最先启用的线程数量。
- CPU 密集型任务（如计算、加解密）：建议设为 CPU 核心数 + 1，减少上下文切换开销
- IO 密集型任务（如数据库查询、HTTP 调用）：可设为 2×CPU 核心数 ~ 4×CPU 核心数，利用等待时间提升吞吐
- 混合型任务：避免“一池多用”，应按任务类型拆分线程池，各自独立配置
- 注意：核心线程默认永不销毁；若需回收，必须显式调用
allowCoreThreadTimeOut(true)
maximumPoolSize：守住“弹性上限”
它和 workQueue 类型强绑定——只有队列满时才真正起作用。设太高易耗尽系统资源，设太低则任务堆积或频繁拒绝。
- 搭配 有界队列（如 ArrayBlockingQueue）：推荐设为
corePoolSize + 预估峰值并发量，例如 core=8，预估突发并发 50，则 max=60 左右 - 搭配 SynchronousQueue：max 可设高些（如 200），因该队列不存任务，靠快速扩容应对瞬时压力
- 避免设为
Integer.MAX_VALUE：这等同于 newCachedThreadPool，高并发下可能创建数千线程，引发 CPU 打满或 OOM
workQueue：选对“缓冲区性格”
队列类型直接决定线程池是“优先排队”还是“优先扩容”，它是行为分水岭。
立即学习“Java免费学习笔记（深入）”；
- ArrayBlockingQueue（有界）：生产首选。容量明确，配合拒绝策略可精准控流，防止内存失控
- SynchronousQueue（零容量）：不缓存任务，提交即要求线程执行，逼迫线程池优先扩容，适合低延迟场景
- LinkedBlockingQueue（无界，默认容量 Integer.MAX_VALUE）：表面“不丢任务”，实则掩盖背压问题，高并发下极易堆内存溢出，禁止在生产环境直接使用
keepAliveTime + unit：管好“临时员工”的去留
该超时仅对超出 corePoolSize 的非核心线程生效，目的是在流量回落时及时释放资源。
- 常见值：30 秒或 60 秒。太短（如 1 秒）会导致频繁创建/销毁线程，增加开销；太长（如 10 分钟）则空闲线程长期占资源
- 单位必须匹配数值，例如
60L, TimeUnit.SECONDS，不能误写成毫秒单位 - 慎用 0 值：JDK 8+ 对 keepAliveTime=0 有特殊处理，可能立即回收线程，行为不稳定
threadFactory 和 handler：补全可观测性与兜底逻辑
这两个参数常被忽略，却是线上稳定运行的关键支撑。
-
threadFactory：至少应命名线程，例如
new NamedThreadFactory("order-pool")；更佳实践是设为守护线程、添加业务标识，方便线程堆栈定位 -
handler（拒绝策略）：默认 AbortPolicy 直接抛异常，生产更推荐
CallerRunsPolicy——由提交任务的线程自己执行，既不丢任务，又自然降速，缓解压力
不复杂但容易忽略：七个参数必须整体权衡。比如调大 corePoolSize 后，若没同步调整队列容量或拒绝策略，可能让任务在错误环节堆积；又比如用了无界队列却把 maximumPoolSize 设得再大也无意义。真正的配置，是让每个参数都服务于你的业务节奏和系统边界。
