线程池任务执行流程全解析

线程池的 execute() 方法远非简单地“扔任务给线程执行”，而是一套严谨、状态敏感的多阶段决策流程：从空任务校验、核心线程创建、队列入队（含关键二次状态检查）、到非核心线程扩容，每一步都受当前线程数、队列容量和池状态动态制约；任务入队不等于立即执行，SynchronousQueue 会绕过队列直触扩容，非核心线程超时退出是常态，核心线程默认永驻却常被误判为“消失”，而拒绝策略触发更不意味着任务丢失——它可能早已安静躺在队列中等待唤醒。真正掌控线程池，不在于调参技巧，而在于看清任务在 if-else 链中何时脱离你控制的精确边界，这决定了监控埋点、日志追踪与容错降级的关键位置。

execute() 方法里到底发生了什么

调用 executor.execute(Runnable) 的瞬间，线程池不是“直接扔给线程去跑”，而是一套带状态检查和条件分支的决策链。它不保证立即创建线程，也不保证立即执行——关键看当前线程数、队列容量和线程池状态。

• 先判空：command 为 null 直接抛 NullPointerException，别等运行时才发现传了空任务
• 再看核心线程：如果 workerCount < corePoolSize，就走 addWorker(command, true) 创建核心线程——注意，这步要抢 mainLock，高并发下可能短暂阻塞
• 否则尝试入队：workQueue.offer(command) 成功后，**必须二次检查线程池状态**（因为从判断到入队不是原子操作）；若此时已 SHUTDOWN，就得把刚塞进去的任务撤回并触发拒绝策略
• 最后才考虑扩容：只有队列满了 且 当前线程数 < maximumPoolSize，才调 addWorker(command, false) 创建非核心线程

为什么任务进了队列却迟迟不执行

这不是 bug，是设计使然：只要核心线程没满，线程池优先创建线程；但一旦核心线程已满，它会「无条件先入队」，哪怕队列里已有 100 个任务、而此刻有 3 个空闲核心线程在休眠——因为那些线程正在执行 getTask()，从队列里取任务，取不到就阻塞等待，不会主动“扫”队列。

• 典型现象：提交 10 个任务，corePoolSize=2，前 2 个立刻执行，后 8 个全进队列，但第 3 个任务要等前 2 个中的某一个执行完、调用 workQueue.poll(keepAliveTime, unit) 拿到下一个，才会开始处理
• 陷阱：用 SynchronousQueue 时，它不存任务，offer() 永远返回 false，导致跳过入队直接走扩容逻辑——容易误以为“队列没生效”，其实是它根本没队列
• 调试建议：重写 beforeExecute 和 afterExecute，打日志看每个任务实际何时被哪个线程 pickup，比光看提交顺序更真实

非核心线程怎么死？为什么有时 core 线程也消失了

非核心线程空闲超 keepAliveTime 就会被 getTask() 返回 null，然后 Worker 自行退出循环、销毁自身——这是唯一正常退出路径。但核心线程默认「永生」，除非你显式调了 allowCoreThreadTimeOut(true)。

• 常见误判：看到线程数回落到 corePoolSize 就以为“核心线程被回收了”，其实只是非核心线程退场，核心线程仍在 waiting 状态，随时准备拉活
• 危险配置：allowCoreThreadTimeOut(true) + keepAliveTime=1 秒 → 核心线程空闲 1 秒就销毁，下次任务来又要重建，完全失去“常驻”意义
• 验证方法：用 jstack 查看线程名（如 pool-1-thread-3），对比线程数变化前后是否出现新编号——编号重用说明是复用，全新编号大概率是重建

拒绝策略触发时，你以为的任务丢了，其实可能早就在队列里了

RejectedExecutionException 不代表“任务根本没进线程池”，而是说在 execute 流程的最后一步：addWorker(command, false) 失败了（比如已达 maximumPoolSize），才走到 handler.rejectedExecution()。但此前若入队成功，任务已在 workQueue 中安顿好，只是你没感知到。

• 典型错觉：开一个 core=2, max=4, queue=10 的池，提交 17 个任务，第 17 个触发拒绝——但前 16 个中，前 2 个在执行，中间 10 个在队列，最后 4 个是非核心线程在跑；拒绝的是第 17 个，不是前面的
• 选策略别只看文档：用 CallerRunsPolicy 时，拒绝任务由提交线程自己执行，若该线程是 Tomcat 的 worker 线程，等于把业务逻辑拖进容器线程里跑，可能卡住整个请求链路
• 真要丢任务？用 DiscardPolicy；想保命？自定义 handler，在拒绝前把任务发到 MQ 或落库，后续补偿——但得承担重复消费或延迟问题

线程池不是黑盒，它的每一步决策都暴露在 execute() 的 if-else 里。真正难的不是配参数，而是理解「任务在哪一刻真正脱离你的掌控」——是在 offer() 返回 true 时？还是在 addWorker() 启动线程时？还是在线程调用 run() 的那一行？这个边界，决定了你加监控、打日志、做降级的位置。

到这里，我们也就讲完了《线程池任务执行流程全解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！