企业官网建设流程全解析

1. 从一次差点翻车的事故说起：线程池到底管什么

两年前我接手过一个内部运营系统的维护任务，某天晚上十点多，监控突然报警，接口平均响应时间从 80ms 涨到了 8 秒，紧接着一堆超时异常轰炸日志。查了半天才发现，罪魁祸首是前人留的一段代码：每次请求进来都new Thread(() -> { ... }).start()，高峰期线程数瞬间冲到上千个，CPU 被打满，上下文切换把系统彻底拖垮。那次事故之后，我把这个模块的所有异步逻辑全部改造成线程池，才算消停。

这就是我写这篇 ThreadPoolExecutor 详解的出发点。很多同学对线程池的理解停留在"背八个参数"或者"能用 Executors 静态方法就行"，但真正上了生产环境，参数怎么配、队列怎么选、拒绝策略怎么定、线程如何回收、监控怎么埋点，每一环都藏着坑。这篇文章不打算讲太多教科书式的定义，我想把 ThreadPoolExecutor 从构造参数到任务流转、再到调参和排查，用一线的视角完整捋一遍。适合已经被corePoolSize、maximumPoolSize搞糊涂的入门读者，也适合那些想把自己的线程池从"能跑"优化到"稳跑"的进阶开发者。看完你至少能回答三个问题：线程池是怎么工作的、为什么不建议随手用Executors的便捷方法、以及线上线程池出了问题该往哪儿查。

2. 构造函数里的七个参数：每一个都有存在理由

2.1 核心线程数与最大线程数：先搞清楚谁是"正式工"谁是"临时工"

ThreadPoolExecutor最常用的构造函数有七个参数，大部分人的记忆难点不在于参数含义，而在于它们之间的联动关系。我习惯用开公司的逻辑来类比，这样好记也好讲。

• corePoolSize：正式员工数量。不管活多活少，这部分线程常驻，除非设置了allowCoreThreadTimeOut(true)，否则即使空闲也不会被回收。
• maximumPoolSize：公司最多能容纳的总员工数。等于正式工加上临时外援的上限。
• keepAliveTime和unit：临时工的试用期。非核心线程空闲超过这个时间就会被裁掉。
• workQueue：待办事项的队列。正式工忙不过来的时候，新任务先排队，而不是立刻招临时工。
• threadFactory：招聘渠道。用来给每个线程命名、设置守护状态。
• handler：公司实在塞不下人时的应对策略，也就是拒绝策略。

很多人在初学时会背一句话：当提交的任务数大于corePoolSize，且队列已满时，线程池会创建新线程直到达到maximumPoolSize。这句话本身没毛病，但容易让人误以为"队列一满就立刻扩张线程"，实际上线程池的扩张顺序是：先让核心线程干活，核心线程忙不过来了就丢进队列，队列满了才开始加非核心线程，加到maximumPoolSize还是不够，才触发拒绝策略。

这个顺序特别关键。我见过有人把corePoolSize设成 200，maximumPoolSize设成 400，队列用无界队列，结果上来就被流量打爆，因为队列根本不会满，线程数永远停在 200，临时工一个都没被雇用。后面讲任务流转的时候我还会再展开。

2.2 工作队列与拒绝策略：决定了线程池的性格

workQueue是线程池里最容易出问题的地方，因为它直接决定了任务的排队方式。常见的选项有三个：

• SynchronousQueue：不存储任务，每个插入操作必须等待另一个线程的移除操作。用它意味着只要核心线程忙，就立即创建新线程，适合对响应时间敏感、不希望任务积压的场景。
• LinkedBlockingQueue：基于链表的无界队列（也可以指定容量），任务可以无限排队。日常用Executors.newFixedThreadPool得到的线程池就是它 + 无界队列。
• ArrayBlockingQueue：有界队列，必须指定容量，适合需要限制排队量的场景。

这里有一个非常隐蔽的坑：如果你用了无界队列，那么maximumPoolSize和拒绝策略基本就废了。因为任务永远不会填满队列，线程池永远不会创建超过corePoolSize的线程，也不会触发拒绝策略。换句话说，你的线程池实际上被固定成了corePoolSize个线程，剩下的参数形同虚设。

拒绝策略RejectedExecutionHandler有四种内置实现：

1. AbortPolicy：直接抛RejectedExecutionException，默认策略。
2. CallerRunsPolicy：不抛异常，会让提交任务的那个线程自己去执行这个任务。
3. DiscardPolicy：静默丢弃任务，啥也不干。
4. DiscardOldestPolicy：丢弃队列中最老的任务，然后把新任务塞进去。

我个人的建议是：大多数业务场景用CallerRunsPolicy会比AbortPolicy更稳妥，因为当线程池满了，说明系统已经到了瓶颈，这时候让调用线程亲自执行，相当于一种隐式的背压，能拖慢提交方的速度，给系统喘息的机会。当然，如果任务是纯异步的、可以接受丢弃，也可以自定义策略做告警和降级。

2.3 其他参数里藏着的细节：线程工厂与拒绝策略缺一不可

threadFactory这个参数经常被忽略，但它是线上排查的一把钥匙。如果你不自定义，JDK 默认生成的线程名字是pool-1-thread-1这种格式，一旦系统里线程池多了，你根本分不清某个线程是哪个业务模块创建的。我每次在项目里都会用一个自定义工厂，把业务名写进线程名，比如order-async-pool-thread-1，这样出问题的时候jstack一看就知道是谁家的线程在搞事情。顺带还会把线程设为非守护线程，避免因为主线程结束导致任务丢失。

还有一点容易被误解的是allowCoreThreadTimeOut参数。它默认是false，如果你把它设为true，核心线程也会在空闲超过keepAliveTime后退出，可以配合SynchronousQueue实现"线程数随负载伸缩"的效果。不过要注意，这个设置通常需要配合setKeepAliveTime使用，而且在低峰期反复创建和销毁线程的开销也不小，适合对资源占用敏感但任务量波动大的场景。

3. 任务在池里的完整流转：从execute到runWorker

3.1execute方法的决策树：每次提交都是一次条件判断

很多人用线程池只是把任务往execute或者submit里一扔，但没想过这背后发生了什么。其实execute的源码逻辑并不复杂，可以用三步来概括。

第一步：如果当前线程数小于corePoolSize，那就直接创建一个 Worker 线程来执行这个任务。这一步的判断即使在核心线程已经空闲的情况下也会成立，所以线程池倾向于通过新建线程来响应新任务，而不是复用空闲线程，这是它"先开人、后排队"的性格。

第二步：如果当前线程数已经大于等于corePoolSize，就把任务放进workQueue。注意这里并不在乎核心线程有没有空闲，只看线程总数是否达到核心数。进了队列之后，线程池会再次检查线程池状态，如果发现池子已经关闭就会拒绝这个任务；如果发现没有线程存活，会补建一个线程。

第三步：如果队列也放不进去，就尝试调用addWorker创建非核心线程。如果线程数已经达到maximumPoolSize，或者线程池状态不合法，就会走向拒绝策略。

这个决策树理解透了，你就能解释很多奇怪的现象。比如为什么corePoolSize=10、maximumPoolSize=20、有界队列容量为 100 的情况下，前 10 个任务会立刻执行，第 11 到第 110 个任务会排队，而第 111 个任务才开始创建新线程。很多面试题里喜欢问"先扩线程还是先排队"，答案就是先排队。

3.2 Worker 线程生命周期：AQS 与任务循环

线程池里的每个线程其实被包装成了一个Worker对象，这个对象继承自AbstractQueuedSynchronizer（AQS）。为什么要用 AQS？因为Worker需要支持两种状态：一种是正在干活时不能被中断，另一种是空闲时可以被中断以便关闭线程池。AQS 正好提供了一种简单的互斥机制，lock()表示开始干活时上锁，此时外部调shutdownNow不会中断它；干完活后unlock()解锁，如果线程池正在关闭，空闲的 Worker 就会被中断掉。

每个 Worker 启动之后会进入一个while循环：不断从任务队列里取任务，执行完之后再取下一个。取任务有两个方法，poll和take，区别在于前者会等待keepAliveTime时间然后返回 null，后者会一直阻塞直到有任务。线程池内部正是通过控制getTask()使用哪种方式来管理线程的回收：核心线程用take（除非设置了allowCoreThreadTimeOut），非核心线程用poll，超时返回 null 之后 Worker 就会退出，线程数随之减少。

这里有一个值得注意的性能细节：当一个任务执行完毕，Worker 并不会立刻销毁，而是会再次尝试取任务，这就避免了频繁创建线程的开销。也正是因为这个循环机制，线程池里的核心线程才能真正实现"常驻"。

3.3 从execute到submit的分岔：Future 是怎么来的

大多数业务代码用的不是execute而是submit，因为后者能拿到返回值或者异常。submit内部把Runnable或者Callable包装成一个FutureTask，最后调用的还是execute。这意味着线程池对任务本身的类型并不敏感，它只负责执行，任务的返回值、异常传播都由FutureTask来处理。

但这里有一个坑：如果你在任务里抛了异常，execute提交的任务会直接让 Worker 线程挂掉，异常会打印在日志里但线程池会默默补一个新的 Worker；而submit提交的任务会把异常封装在返回的Future里，如果你不调用future.get()，异常会被吞掉，日志里什么都不会有。我在排查线上问题时至少碰到过三次"任务神秘消失"，最后都发现是submit之后没调get，异常被吞了。所以，用submit的代码，要么记得接结果，要么在任务内部自己 catch 住异常打日志。

4. 参数估算与动态线程池改造：调参不能拍脑袋

4.1 两种常见的参数估算思路

面试的时候最常被问到"线程池大小怎么设置"，标准的回答是分 CPU 密集型和 IO 密集型：

• CPU 密集型任务：公式大致是CPU 核数 + 1。因为这类任务几乎不阻塞，多出来的线程只会增加上下文切换开销。
• IO 密集型任务：公式可以粗算为CPU 核数 * 2，更精确一点是CPU 核数 / (1 - 阻塞系数)，阻塞系数通常在 0.8 到 0.9 之间。也就是说，如果任务有 80% 的时间在等待 IO，那么理论上线程数可以是 CPU 核数的 5 倍。

但说实话，这些公式只能给出一个起点，真实线上环境受内存、GC、下游服务吞吐量的影响很大。我更推荐的做法是先跑一轮压测：在压测环境下用不同的线程数跑同样的任务，观测吞吐量和响应时间随线程数的变化曲线，找到拐点。我曾经调过一个日志清洗任务，核心线程从 4 加到 8，吞吐量直接翻倍，再加到 16，反而因为争抢数据库连接导致性能下滑。这正好说明线程数不是越大越好，最终瓶颈往往不在 CPU，而在下游资源。

4.2 队列容量怎么定：别让请求变成闲置库存

队列容量的选择是调参里最容易失衡的地方。队列太小，稍有流量波动就会触发拒绝策略；队列太大，任务积压后一旦系统恢复，又会瞬间处理大量过期任务，反而拖垮下游。

我习惯用一个经验值：让队列容量等于corePoolSize的 2 到 3 倍，同时配合一个"队列积压数"的监控指标。当积压数持续增长时，说明消费速度跟不上生产速度，这时候需要思考是扩线程还是降流量，而不是傻等队列自动消化。对于实时性要求高的系统，甚至可以放弃队列，直接使用SynchronousQueue，让线程池的弹性完全交给非核心线程。这种做法的代价是线程创建销毁会更频繁，需要合理配置keepAliveTime，不能太短，否则高峰期的抖动会非常剧烈。

说到这必须再强调一次：不要用Executors.newFixedThreadPool来创建线程池。它的默认队列是无界LinkedBlockingQueue，一旦任务提交速度长期大于消费速度，队列会无限增长，最终导致内存溢出。这几乎是每个团队都会踩的坑，我在代码评审里看到类似写法都会直接打回改造成显式构造ThreadPoolExecutor。

4.3 动态线程池：让参数可以随时调整

生产环境有个很现实的问题：参数配得再合理，也架不住业务流量突变。比如大促前你预测峰值，手动调高了核心线程数，但活动结束后忘记调回来，系统就会长期低负载运行。所以现在很多团队会做动态线程池。

JDK 的ThreadPoolExecutor其实已经提供了调整参数的接口：setCorePoolSize、setMaximumPoolSize、setKeepAliveTime。调用setCorePoolSize时，线程池会动态调整正在运行的线程数，如果新设置的值比当前核心线程数小，空闲线程会被逐步回收。setMaximumPoolSize同理，只是它不影响已运行的线程，只限制后续扩张。

我的做法是把线程池的配置放到配置中心里，然后用一个后台线程定期同步参数。同步之前先通过getPoolSize、getActiveCount、getQueue().size()这几个方法拿到当前状态，再决定要不要调整，避免在高峰期贸然缩容。另外，prestartAllCoreThreads()这个方法也值得提一下，它可以在系统启动时就预先创建所有核心线程，避免第一个任务到达时因为创建线程而延迟。对延迟敏感的初始化阶段，这个方法很实用。

5. 故障场景实录：线程池出问题时怎么查

5.1 案例一：无界队列导致的内存与线程堆积

有个某电商促销项目，用户下单后会异步发送一堆消息。开发图省事用了Executors.newFixedThreadPool(20)，顺便把线程池对象定义成了静态变量。结果某次下游消息服务响应极度变慢，消息积压越来越多，队列长度涨到了几百万条，最终老年代内存持续增长，触发了 Full GC，整个应用几乎卡死。

排查思路其实很直接：先看jstat -gcutil确认内存状况，再用jstack抓线程栈，发现大量线程阻塞在LinkedBlockingQueue.put上，再看业务日志里的消息发送耗时，就基本能定位。修复方案是弃用无界队列，改成有界队列 + 自定义拒绝策略（比如丢弃并记录告警），同时在下游服务恢复后通过重试机制补发。从那次之后我们团队定了一个规矩：凡是线程池必须用显式构造，队列必须有界。

如果你现在也在用Executors的便捷方法，建议尽早自查一下，特别是newFixedThreadPool和newSingleThreadExecutor这两兄弟，它们的无界队列在流量突刺时真的很危险。

5.2 案例二：核心线程数配置过大导致的线程饥饿

另一个有意思的故障不是线程不够，而是线程太多。某批处理系统给线程池配置了corePoolSize=100、无界队列，看起来性能很充足。但任务大部分是调用第三方 API，耗时 1 到 3 秒不等。问题在于，这个线程池的任务里还嵌套了另一个同样大线程数的线程池，形成了 A 池任务等待 B 池任务完成的依赖关系。当 A 池 100 个线程全部占满，B 池又没有线程可用时，就出现了线程饥饿，表现为 A 池的任务队列不停堆积，但每个任务都卡在等待 Future 上。

这种问题的排查难点在于线程栈看起来都"正常阻塞"，没有死锁。我当时的排查步骤是：先看jstack里大量park状态的线程，再检查代码里的线程池调用链，发现嵌套关系后，将依赖子任务的部分改造成单独的线程池，并给小池子设置更小的corePoolSize和更短的超时，同时给 A 池的keepAliveTime设置了合理值以便非高峰时回收。线程饥饿的本质是资源都被无效占用了，而不是资源不够，所以在设计时就要尽量避免一个线程池任务再去依赖另一个线程池。

5.3 监控与告警：线程池里的四大核心指标

平时不监控，出了问题只能靠日志猜，这是线程池运维最大的痛点。我建议至少给每个线程池埋上四个指标。

• getPoolSize()：当前线程数，结合getActiveCount()看实际干活的有多少。
• getQueue().size()：队列积压数，这是最敏感的指标。
• getTaskCount()和getCompletedTaskCount()：累计完成任务数，可用差值评估处理速率。
• 拒绝次数：这个需要自定义RejectedExecutionHandler，在拒绝逻辑里埋点累加。

在 Java 层面可以用 Micrometer 或者简单的ThreadPoolExecutor包装类暴露指标，如果不想引入额外依赖，也可以写一个定时任务，每隔 10 秒采集一次并记录到日志。有了数据就能做告警规则：队列积压数连续 3 次超过阈值，或者拒绝次数大于 0，就触发告警。坦率地讲，大部分线程池问题在发生之前都是有可观测信号的，关键是你有没有把它接进监控体系。

6. 最后再分享几个我自己的使用习惯

线程池这个东西，用好了是性能利器，用不好是隐性地雷。最后分享几个我这些年沉淀下来的小习惯，谈不上标准答案，但每一招都来自实战教训。

• 线程池对象尽量用静态内部类持有，不要散落在方法里到处创建。每次new ThreadPoolExecutor都是在浪费资源，而且会导致线程无法复用。
• 给每个池子取业务相关的前缀名字，这是成本最低的排查手段。
• 显式设置拒绝策略，并且一定在拒绝策略里打日志，宁愿多打一条日志也不要静默丢弃。
• 用完的线程池要想到关闭。如果一个线程池是某个模块独有的，在应用关闭时应该调用shutdown()或shutdownNow()，别让它把 JVM 退出拖慢几秒钟。

我个人在实际操作中还有一个体会：调线程池参数的时候，永远只调一个变量，观察一段时间再做下一次调整。很多人喜欢一次性把核心线程、队列容量、拒绝策略全改了，出了问题根本不知道是哪个变量引起的。线程池是并发系统的核心组件，谨慎一点，系统就会稳一点。