3. 线程池核心架构解剖
线程池并不是“把线程装进一个池子”这么简单。它本质上是一套任务提交、任务排队、线程复用、容量控制与过载保护的协作系统。要真正掌握线程池，必须把它拆成五个核心部件来看：核心参数、工作队列、线程工厂、拒绝策略，以及它们之间的整体协作流程。只有理解这五者如何互相牵制，才能在工程中判断“为什么任务被拒绝”“为什么线程数不涨”“为什么队列堆积导致延迟飙升”。
一、核心参数：线程池的容量骨架
以 Java 的 ThreadPoolExecutor 为例，最关键的参数有七个：corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。它们不是孤立配置项，而是一组互相约束的容量规则。
- corePoolSize：常驻核心线程数。任务到来时，若当前工作线程数小于核心线程数，线程池会优先创建新线程执行任务，而不是先入队。
- maximumPoolSize：线程总数上限。只有当工作队列已满，且当前线程数小于最大值时，才会继续创建非核心线程。
- keepAliveTime / unit：非核心线程空闲后的存活时间；若开启
allowCoreThreadTimeOut，核心线程也会受此影响。 - workQueue：承载待执行任务的阻塞队列，决定任务的排队行为与容量边界。
- threadFactory：负责创建线程，可统一命名、设置优先级、守护状态与异常处理器。
- handler：当线程池无法继续接收任务时的拒绝策略。
这里有一个容易被忽略的顺序：先核心线程，再入队，队列满后才扩到最大线程，最后才拒绝。很多“线程数上不去”的问题，根源就是使用了无界队列——队列永远不满，maximumPoolSize 永远不会被触发。
二、工作队列：排队策略决定系统性格
工作队列是线程池的“缓冲带”，也是延迟与吞吐的调节器。常见队列类型及其工程含义如下：
| 队列类型 | 容量特征 | 典型影响 |
|---|---|---|
| ArrayBlockingQueue | 有界数组队列 | 容量可控，队列满后可触发扩容与拒绝，适合稳定过载保护 |
| LinkedBlockingQueue | 默认近似无界（Integer.MAX_VALUE） | 队列几乎不会满，maximumPoolSize 形同虚设，易堆积导致内存与延迟风险 |
| SynchronousQueue | 不存储任务，直接移交 | 任务必须立刻被线程接收，否则创建新线程或拒绝，适合高吞吐短任务 |
| PriorityBlockingQueue | 按优先级出队 | 可做优先级调度，但需注意低优先级任务饥饿 |
| DelayQueue | 延迟到期才可出队 | 适合定时/延迟任务，但线程可能长时间空转等待 |
选择队列时，核心问题是：你希望系统在过载时“排队等待”还是“快速失败”？如果希望保护下游、控制内存，就应有界队列配合合理拒绝策略；如果任务短小且线程充足，SynchronousQueue 能减少排队延迟。队列容量不是越大越好，容量越大，任务等待时间越长，超时与雪崩风险越高。
三、线程工厂：线程的“出生证明”
线程工厂看似简单，却直接影响排障效率。默认线程工厂创建的线程名类似 pool-1-thread-1，在线程 dump 中很难定位业务归属。工程中通常自定义线程工厂，统一命名规则，例如 order-task-pool-3，并设置是否为守护线程、异常处理器与优先级。
ThreadFactory factory = new ThreadFactory() {
private final AtomicInteger seq = new AtomicInteger(1);
public Thread newThread(Runnable r) {
Thread t = new Thread(r, "order-task-pool-" + seq.getAndIncrement());
t.setDaemon(false);
t.setUncaughtExceptionHandler((thread, ex) ->
log.error("task failed in {}", thread.getName(), ex));
return t;
}
};命名规范让日志、监控和线程栈能快速关联到具体线程池；异常处理器则避免任务异常被静默吞掉。若使用 submit 提交任务，异常会被封装进 Future，不调用 get() 就不会抛出，这一点尤其需要配合监控。
四、拒绝策略：过载时的最后一道闸门
当线程数达到最大值且队列已满，线程池必须拒绝新任务。JDK 提供四种内置策略：
- AbortPolicy：直接抛出
RejectedExecutionException，默认策略，适合必须感知失败的场景。 - CallerRunsPolicy：由提交任务的线程自己执行，形成天然背压，降低提交速度，但可能阻塞调用方。
- DiscardPolicy：静默丢弃，不抛异常，风险最高，通常只用于可丢失任务。
- DiscardOldestPolicy：丢弃队列中最旧任务再尝试提交，可能丢失重要任务。
生产环境更推荐自定义拒绝策略：记录被拒任务的关键信息、输出监控指标、必要时落盘或转入降级队列。拒绝策略不是“兜底代码”，而是系统过载时的可观测入口。
五、整体协作流程：一张图看清任务去向
把上述部件串起来，任务提交后的判断路径如下：若工作线程数小于核心线程数，直接创建核心线程执行；否则尝试入队；若队列未满则排队等待；若队列已满且线程数小于最大值，则创建非核心线程；若仍无法接收，则交给拒绝策略。整个过程由 ctl 原子变量统一管理线程状态与数量，保证并发安全。
六、参数配置的工程判断
理解架构后，配置才有依据。CPU 密集型任务，线程数通常接近 CPU 核数，避免过多上下文切换；I/O 密集型任务，线程数可适当放大，但必须配合有界队列与拒绝策略，防止无限堆积。队列容量应结合任务平均处理时间、可接受等待延迟和内存占用估算。例如，单任务对象约 1KB，队列容量 10000，则仅排队任务就占用约 10MB，若任务持有大对象则需重新评估。
- 线程池是否有明确业务命名？
- 队列是否有界？容量依据是什么？
- 拒绝策略是否可观测、可告警？
- 是否监控 activeCount、queueSize、completedTaskCount、rejectedCount？
- 核心线程是否允许超时回收？是否符合流量潮汐特征？
Executors.newFixedThreadPool 或 newSingleThreadExecutor 时，底层使用无界 LinkedBlockingQueue，任务可无限堆积，最终可能 OOM。生产环境建议直接使用 ThreadPoolExecutor 显式指定全部参数。
线程池的架构解剖最终要落到一个判断上：任务从提交到执行，每一步的容量边界在哪里，过载时系统如何表现。核心参数定义容量，工作队列定义缓冲，线程工厂定义线程身份，拒绝策略定义过载行为，而整体协作流程把它们串成一条可观测、可控制的执行链。掌握这条链，才能从“会用线程池”走向“能治理线程池”。