Java线程池的核心在于参数配置与稳定性，其执行遵循四步决策链：先创建核心线程，再入队，然后创建非核心线程，最后触发拒绝策略；状态机由RUNNING到TERMINATED严格转换；应避免Executors工厂类，推荐自定义ThreadPoolExecutor并显式设置有界队列、合理线程数、自定义ThreadFactory和拒绝策略；submit比execute更利于异常感知。
Java线程池的核心不在“怎么用”，而在“怎么配”和“怎么稳”。真正决定系统能否扛住高并发、不OOM、不丢任务的，是 ThreadPoolExecutor 的七个参数协同逻辑，以及它背后的状态机与任务调度策略。
线程池不是黑盒，而是有明确执行优先级的流水线
任务进来后，并非随机分配——它严格遵循四步决策链：
- 当前线程数 < corePoolSize → 立即创建核心线程执行（不入队）
- 否则尝试加入 workQueue → 入队成功则等待空闲线程取走
- 队列已满且当前线程数 < maximumPoolSize → 创建非核心线程紧急处理
- 否则触发拒绝策略（如 AbortPolicy 抛异常、CallerRunsPolicy 由提交线程自己执行）
这个顺序不能跳过，也不能倒置。比如用 无界队列（LinkedBlockingQueue）时，maximumPoolSize 实际失效，所有超额任务都会堆积在内存里，极易引发 OOM。
五个状态控制着线程池的生死节奏
ThreadPoolExecutor 内部用一个 int 原子变量（ctl）同时存状态（高3位）和线程数（低29位）。关键状态转换如下：
立即学习“Java免费学习笔记（深入）”；
- RUNNING：接收新任务 + 处理队列中任务
- SHUTDOWN：不接收新任务 + 继续处理队列中任务（调用 shutdown() 进入）
- STOP：不接收新任务 + 不处理队列任务 + 中断正在运行的线程（调用 shutdownNow() 进入）
- TIDYING：所有任务结束、线程数为0 → 自动进入此状态，准备终止
- TERMINATED：terminated() 方法执行完毕 → 彻底终结
注意：shutdown() 后线程池不会立刻停，必须配合 awaitTermination() 才能安全等待；而 shutdownNow() 是强中断，但不保证正在运行的任务一定停止（需任务自身响应中断）。
别迷信 Executors 工厂类，自定义才是生产标配
Executors 提供的 newFixedThreadPool、newCachedThreadPool 等方法看似方便，但存在隐患：
- newFixedThreadPool 使用无界队列 → 任务积压导致内存溢出
- newCachedThreadPool 允许创建 Integer.MAX_VALUE 个线程 → 突发流量可能打爆系统
- 默认 ThreadFactory 创建的线程名无业务标识 → 排查问题时无法区分来源
推荐直接使用 ThreadPoolExecutor 构造器，显式控制：
- 有界队列（如 ArrayBlockingQueue(100)）防止无限堆积
- 合理设置 core/max（CPU 密集型 ≈ CPU 核数，IO 密集型可适当放大）
- 自定义 ThreadFactory 设置线程前缀（如 "order-service-pool-"）
- 指定 RejectedExecutionHandler 避免静默失败（如记录日志+降级）
任务提交方式影响结果获取与异常处理
execute() 和 submit() 行为差异明显：
- execute(Runnable)：只执行，不返回结果，异常会直接抛到线程的 UncaughtExceptionHandler（若未设置则打印堆栈后消失）
- submit(Runnable/Callable)：返回 Future，异常被封装进 Future.get()，必须主动调用 get() 才能感知失败
对关键业务任务，建议统一用 submit + try-catch get()，确保异常不被吞掉；异步通知类任务可用 execute，但务必配置全局 UncaughtExceptionHandler。
