corePoolSize是新任务提交时立即创建线程的阈值，而非“最小线程数”；当线程数未达corePoolSize时，新任务触发即时线程创建，否则进入队列或按拒绝策略处理。
corePoolSize不是“最小线程数”，而是“优先创建线程的阈值”
很多人误以为 corePoolSize 是线程池“至少维持”的线程数，其实它更准确的角色是：**新任务提交时，是否立即创建线程的开关阈值**。只要当前线程数 corePoolSize，不管有没有空闲线程，都会新建线程去执行——哪怕已有 1 个线程正休眠在 Thread.sleep(10000) 中，第 2 个任务来了仍会起第 2 个线程（假设 corePoolSize=2）。
- 默认情况下，核心线程永不回收（即使空闲），除非调用
allowCoreThreadTimeOut(true) - 若用
LinkedBlockingQueue且未指定容量（即无界队列），maximumPoolSize实际失效：因为队列永远不会满，永远不触发非核心线程创建 - 想让线程池真正“弹性伸缩”，必须配**有界队列**（如
ArrayBlockingQueue(10)）+corePoolSize
workQueue选错，等于白配maximumPoolSize
队列类型直接决定线程池是否能走到“扩容到最大线程数”这一步。常见错误是直接用 new LinkedBlockingQueue()（无界），结果无论并发多高、任务多猛，线程数永远卡在 corePoolSize，内存却悄悄涨到 OOM。
-
ArrayBlockingQueue：有界，推荐生产使用；队列满 → 触发扩容逻辑 → 达到maximumPoolSize后触发拒绝策略 -
SynchronousQueue：不存任务，相当于“快递员直送”；适合CachedThreadPool场景，要求快速响应、任务轻量 -
PriorityBlockingQueue：无界 + 优先级；注意：它不保证公平性，且拒绝策略可能因无法判断“最旧任务”而行为异常
keepAliveTime只对非核心线程生效，除非你主动破戒
keepAliveTime 默认管不了核心线程——这是设计使然，不是 bug。它的本意就是让“临时工”干完活就走，而“正式工”（核心线程）常驻待命。如果你发现线程池缩容不下来，先检查是不是忘了设置 allowCoreThreadTimeOut(true)。
- 设置了
allowCoreThreadTimeOut(true)后，所有线程（含核心）都受keepAliveTime约束 - 单位必须匹配
unit参数，写成60, TimeUnit.MILLISECONDS却期望等 60 秒？那线程会在 60 毫秒后全灭 - 该参数在低负载场景下影响显著：比如高峰期开到 50 个线程，之后 1 小时没任务，能否及时回收，全看这个值和是否启用超时
拒绝策略不是兜底，而是系统压测的信号灯
看到 RejectedExecutionException 别急着换 CallerRunsPolicy 来“假装没事”。它暴露的是真实瓶颈：要么队列太小、要么线程上限太低、要么下游处理太慢导致任务积压。
-
AbortPolicy（默认）：抛异常——适合开发/测试环境，快速暴露配置不合理 -
DiscardOldestPolicy：丢队头任务——慎用！若任务有状态依赖或顺序敏感，会引发数据不一致 - 线上建议搭配监控：捕获
RejectedExecutionException并上报指标，作为扩容或限流的触发条件
线程池不是设完参数就一劳永逸的组件，它的行为高度依赖 corePoolSize、workQueue、maximumPoolSize 三者之间的配合关系；少一个环节理解偏差，就可能让整个并发模型在高负载下失速或崩溃。
