java线程池任务流转由corepoolsize、workqueue、maximumpoolsize和拒绝策略协同决策：先尝试创建核心线程；满则入队，入队失败或队满再扩容至maximumpoolsize；全部失效时触发拒绝策略。

Java线程池的任务流转不是线性排队，而是由多个核心组件按规则协同决策的过程。理解它，关键在于看清 corePoolSize、workQueue、maximumPoolSize 和拒绝策略 如何在任务到达的瞬间共同“投票”决定任务去向。

核心线程数：第一道守门人

任务提交时，线程池首先看当前活跃线程数是否小于 corePoolSize：

• 如果未达上限，直接创建新核心线程执行任务——哪怕已有空闲线程也不复用，这是设计使然；
• 核心线程默认长期存活，不因空闲而销毁（除非显式启用 allowCoreThreadTimeOut(true)）；
• 这个阶段不查队列，也不考虑最大线程数，纯粹“优先扩编骨干力量”。

工作队列：缓冲与分流的关键枢纽

当核心线程已满，任务不会立刻扩容，而是尝试进入 workQueue：

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• 入队前会再次校验线程池是否仍为 RUNNING 状态；
• 入队成功后，还会做一次“二次检查”：若此时线程池已非 RUNNING，且任务能从队列中移除，则触发拒绝策略；
• 若队列已满（如 ArrayBlockingQueue 达到容量上限），或根本无法入队（如 SynchronousQueue 拒绝缓存），流程立即进入扩容判断。

最大线程数：弹性兜底的最后防线

只有当队列也满了，且当前线程数仍小于 maximumPoolSize，才会创建非核心线程：

• 这类线程是“救急型”，空闲超过 keepAliveTime 就会被回收；
• 它的存在让线程池具备应对突发流量的能力，但绝不意味着可以无度扩容；
• 一旦线程数已达 maximumPoolSize，且队列满载，就彻底失去承载能力。

拒绝策略：资源饱和时的业务守则

当所有路径都走不通，任务必须被处置，此时 RejectedExecutionHandler 开始生效：

• AbortPolicy（默认）：抛出 RejectedExecutionException，适合强一致性场景；
• CallerRunsPolicy：由提交任务的线程自己执行该任务，可自然降速，避免雪崩；
• DiscardPolicy：静默丢弃，适合日志等低优先级任务；
• DiscardOldestPolicy：丢弃队列头部任务，再尝试提交当前任务，适合希望尽量不丢新任务的场景。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南