线程池这东西很多同学面试前背得滚瓜烂熟核心线程数、最大线程数、阻塞队列、拒绝策略张口就来。但真到了线上环境线程池一打满就日志疯狂报错或者接口突然卡死这时候才发现自己只会背概念根本不知道怎么调。我这些年踩过不少坑也帮别人擦过不少屁股今天就把线程池从参数到实战一次性讲透特别是动态调整这块网上讲得少但恰恰是生产环境最需要的。1. 线程池的核心价值与运行机制1.1 为什么不用裸线程非要搞个线程池先想一个问题创建一个线程到底要花多少钱每次 new Thread 的时候操作系统要分配内核栈、创建线程描述符、建立调度实体再加上JVM自身要分配栈空间默认1MB这可不是一笔小开销。更关键的是线程是稀缺资源一台机器上成千上万个线程同时调度CPU光切换上下文就忙不过来了业务代码反而没时间跑。线程池解决的就是这两个问题一是复用线程避免频繁创建销毁带来的性能损耗二是通过队列做缓冲削峰填谷防止瞬时流量直接把系统打垮。你可以把线程池理解成一个餐馆的后厨厨师线程就那么几个客人点菜任务多了就先排队阻塞队列排队都满了就只能拒绝拒绝策略客人少了就留几个主厨撑着核心线程多余的帮厨可以休息甚至辞退非核心线程回收。1.2 一个任务进来之后经历了什么很多人以为任务提交给线程池就直接执行了其实中间有一套完整的决策流程。简单概括就是先看核心线程有没有空闲的有就让它干没有就试着往队列里塞队列塞不进去才考虑创建非核心线程非核心线程数已经到了最大值那就只能触发拒绝策略了。这里有个特别容易误解的地方很多人以为线程池是先创建线程到最大线程数然后把多余任务放队列顺序搞反了。实际上顺序是核心线程 → 阻塞队列 → 非核心线程 → 拒绝策略。也就是说当核心线程满了之后任务是先去排队排不下了才开始扩容到非核心线程。如果你拿这个顺序去面试或者排查问题会少踩很多坑。2. 七个核心参数逐个拆解2.1 参数列表和各自的作用ThreadPoolExecutor 的构造函数有好几个重载版本最完整的那一个有七个参数public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)corePoolSize核心线程数默认情况下这些线程创建后会一直存活就算闲着也不会被回收除非设置了 allowCoreThreadTimeOut。maximumPoolSize最大线程数表示线程池里最多能同时存在的线程数量包含核心线程和非核心线程。keepAliveTimeunit非核心线程的空闲存活时间。如果非核心线程空闲超过这个时间就会被回收。workQueue阻塞队列用来存放等待执行的任务。threadFactory线程工厂用于创建线程可以自定义线程名、优先级、是否守护线程。handler拒绝策略当队列满了且线程数达到 maximumPoolSize 时新提交的任务该何去何从。2.2 核心线程数的设置思路核心线程数是线程池最关键的一个参数设小了导致频繁排队、吞吐量上不去设大了可能没事干还占着内存。业界有个经典公式CPU密集型任务核心线程数设置为 CPU 核数 1IO密集型任务设置为 CPU 核数 × 2或者用更精细的公式线程数 CPU核数 × (1 等待时间 / 计算时间)wait 时间占比越高说明IO操作越多线程就可以开多一些因为大部分时间线程都在等待IO返回。我拿一个实际项目举例我们的一个订单同步服务每笔订单要调第三方接口平均耗时200ms本地计算耗时50ms机器是4核。按公式算就是 4 × (1 200/50) 20。实际上我调到16就够用了因为第三方接口有并发限制开太多反而把自己这边的线程都占住等IO导致其他任务也进不来。这里说句实在话公式只是起点不是终点。线上环境一定要配合监控数据持续调整我后面在动态调整实战部分会专门讲如何安全地改这些参数。2.3 maximumPoolSize 和 keepAliveTime 的细节最大线程数不是越大越好线程越多CPU上下文切换就越频繁每个线程能分到的CPU时间片就越少。一般来说最大线程数不要超过核心线程数的 2~4 倍除非你的任务真的是纯阻塞型等待比如大量调用外部接口且没有并发限制。keepAliveTime 默认只对非核心线程生效这一点要特别注意。如果你希望核心线程也能被回收需要调用allowCoreThreadTimeOut(true)这在某些资源敏感的场景下很有用。比如一个晚上几乎没什么流量的系统核心线程全闲着也没事干这时候允许核心线程超时回收能省下不少内存。但要注意这个设置一旦开启就不能再关闭了所以生产环境要谨慎使用。另外有个冷门细节如果线程池的当前线程数已经小于 corePoolSize再调用 setCorePoolSize 增加核心线程数只会有新任务提交时才会创建新线程不会立即把所有线程补齐。如果你希望立即补齐可以主动提交一些空任务或者预热任务。3. 四种拒绝策略的选择与实战套路3.1 策略对比当队列满了线程数也到最大值了新任务就会交给拒绝策略处理。JDK 提供了四种内置策略策略名行为适合场景AbortPolicy默认直接抛出 RejectedExecutionException对任务丢失敏感、必须马上感知到过载的场景CallerRunsPolicy由提交任务的线程自己执行不想丢任务、希望自然限流的场景DiscardPolicy悄悄丢弃任务无任何通知允许丢任务、对结果不敏感的场景DiscardOldestPolicy丢弃队列里最早的任务然后重新提交更倾向于处理新任务的场景3.2 实际项目中我最常用的两种默认的 AbortPolicy 其实是个双刃剑。好处是过载立刻暴露日志里能看到异常坏处是如果上游没有兜底逻辑异常会直接抛给调用方一个接口突然报错前端用户看到的就是500。我在某个金融项目里见过这种情况活动期间流量暴增线程池满了之后疯狂抛异常数据库连接池也被打爆最后整个服务不可用。我现在的建议是能不用默认策略就尽量不用。最常用的是 CallerRunsPolicy它的好处是新任务由提交任务的线程自己执行相当于把压力反馈给调用方调用方线程忙着执行任务就会降低向线程池提交新任务的速度天然形成一套背压机制。这种策略下任务不会丢只是整个系统的处理速度会下降但总比丢失请求好得多。用 CallerRunsPolicy 有一个藏得比较深的坑如果提交任务的线程是Tomcat工作线程它去执行任务的时候这个HTTP请求的连接是占着的如果任务耗时很长客户端很可能已经超时断开。任务本质上是白白执行了。所以在使用这种策略前最好评估一下任务耗时和客户端超时时间的关系。如果想要更精细的控制可以自定义 RejectedExecutionHandler。比如短信通知运维、把任务持久化到本地表等时机再捞回来重试这些都需要自己实现。核心逻辑就是记住两件事队列已满、线程已满然后想办法把任务先存下来。3.3 一个比较好用的自定义拒绝策略很多人以为自定义拒绝策略很复杂其实就一个方法。下面这段代码实现了先将任务序列化写入本地文件异步再重试提交回线程池public class PersistTaskRejectedHandler implements RejectedExecutionHandler { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 序列化任务信息这里用数据库存储举例 TaskData taskData TaskData.fromRunnable(r); TaskPersistenceService.save(taskData); // 异步定时扫描任务表重新提交到线程池 TaskRetryService.scheduleRetry(taskData, executor); } }这个策略的好处是任务一个都不丢坏处是实现复杂度高还要考虑持久化的性能和失败补偿。一般来说能让核心业务不丢消息的系统才有必要上这套方案普通业务用 CallerRunsPolicy 就足够了。4. 阻塞队列选择被很多人忽视但极其重要4.1 常用队列的特点和适用场景队列的选择直接决定了线程池的排队行为这个变量往往被忽视实际上它的影响力和核心线程数不相上下。JDK 提供了几种常用的阻塞队列LinkedBlockingQueue默认是无界队列最大Integer.MAX_VALUE使用链表结构。生产上最常见的坑就是用了默认构造函数的 LinkedBlockingQueue任务无限排队导致内存持续增长直到OOM。ArrayBlockingQueue有界队列必须指定容量。数组结构公平性可以配置适合需要严格控制排队长度的场景。SynchronousQueue不存储元素每个插入操作必须等待另一个线程的移除操作反之亦然。所以用它做线程池队列时任务不会排队而是直接找线程执行线程不够就创建非核心线程达到最大值就拒绝。这相当于把队列长度设为0。PriorityBlockingQueue支持优先级排序的无界队列可以让高优先级的任务先执行。DelayedWorkQueue延迟队列ScheduledThreadPoolExecutor 内部使用的就是它。4.2 有界队列优先无界队列慎用Executors 工厂类里那几个现成的方法newFixedThreadPool 默认用的是无界 LinkedBlockingQueuenewCachedThreadPool 用的是 SynchronousQueuenewSingleThreadExecutor 也是无界队列。很多人图方便直接用 Executors 的封装方法这在业务量小的时候没问题但一旦流量上来无界队列的问题就暴露了任务排满内存迟早OOM。我之前排查过一个线上事故一个报表导出接口突然超时最后发现是线程池的队列里积压了几十万个导出任务每个任务对象都持有查询参数和数据集引用直接导致堆内存接近上限。这个事故的根源就是代码里用了Executors.newFixedThreadPool(10)。所以我的建议很直接任何时候都自己 new ThreadPoolExecutor明确指定有界队列的容量。队列容量设置多少要根据任务的平均耗时和期望的排队等待时间来算。比如任务平均耗时100ms你希望最多排队等待2秒那队列容量就是 2秒 / 0.1秒 20。这只是一个粗算实际还要结合系统负载情况调。5. 动态调整实战让线程池“活”起来5.1 为什么需要动态调整很多系统的流量是分时段的白天高峰期每秒几千个请求凌晨可能就几十个。如果线程池参数是一锤子定死的高峰期线程不够用排队严重低峰期大量线程空转白白占用内存。动态调整的核心就是根据实时监控数据在运行期修改线程池的关键参数让线程池始终工作在比较合理的状态。另外经常遇到的一个场景是上线后突然发现某个线程池的拒绝策略被触发日志里疯狂报错。这时候难道要重启服务、改配置再发布吗生产环境哪能这么随随便便所以动态调整的能力在关键时刻能救命。5.2 用什么方法改参数ThreadPoolExecutor 本身提供了几个 set 方法可以在运行期修改参数// 修改核心线程数 threadPoolExecutor.setCorePoolSize(20); // 修改最大线程数 threadPoolExecutor.setMaximumPoolSize(40); // 修改线程存活时间单位是纳秒 threadPoolExecutor.setKeepAliveTime(30, TimeUnit.SECONDS);这几个 set 方法都有对应的 get 方法所以读取当前配置非常简单。但有一个细节必须清楚setCorePoolSize 的效果是渐进式的。如果新值比当前值大线程池不会立刻创建线程而是等新任务来了再逐步创建如果新值比当前值小线程池会尝试回收多余的线程但回收是异步的可能不会立即生效。这意味着动态调参一定要以监控数据为准改完参数之后不能马上判断结果要观察一段时间比如5分钟、10分钟的指标变化。这段观察期要持续监控活跃线程数、队列积压量、任务拒绝数等关键指标。5.3 动态调参的监控指标线程池的监控离不开一套有效的指标采集。我自己常用的做法是继承 ThreadPoolExecutor重写 beforeExecute、afterExecute、terminated 三个钩子方法在每个任务执行前后记录时间从而统计出平均执行时间、最大执行时间等。另外还可以定时输出当前线程数、队列大小等快照信息public class MonitoredThreadPoolExecutor extends ThreadPoolExecutor { public MonitoredThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler) { super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, handler); } Override protected void beforeExecute(Thread t, Runnable r) { super.beforeExecute(t, r); // 记录任务开始时间存到ThreadLocal里 ThreadLocalUtil.setStartTime(System.currentTimeMillis()); } Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); long startTime ThreadLocalUtil.getStartTime(); long cost System.currentTimeMillis() - startTime; ThreadLocalUtil.clear(); // 上报耗时数据比如写入日志或者推送到监控系统 MetricsCollector.record(Thread.currentThread().getName(), cost); } }到这一步很多同学可能会问有了这些指标什么时候该扩容什么时候该缩容我分享一个经验法则当队列积压任务持续增长且活跃线程数长时间等于最大线程数时优先考虑调大 maximumPoolSize同时观察 CPU 使用率当活跃线程数长时间明显低于核心线程数且 CPU 使用率不高时可以调小 corePoolSize回收空闲线程。5.4 业界成熟的动态线程池实现自己造轮子当然可以但业界已经有比较成熟的动态线程池实现方案比如美团开源的动态线程池框架或者说像 hippo4j 这类项目。它们做得比较完善的地方在于可视化控制台、配置热更新、应用内嵌 Agent 上报统计数据。如果你的团队没有精力自己从零做监控和调整系统直接引入这类框架是性价比很高的方案。不过引入第三方框架也要注意版本兼容性、和公司统一监控体系的打通成本。我个人的建议是如果系统规模不大自己写个简单的定时任务 监控采集就够用如果每天核心线程池的执行量级很大多个业务线共用一个服务那这种重一点的框架反而能帮上大忙。5.5 动态调整的综合案例说一个我实际配置过的例子。有一个异步消息推送服务接收上游的业务消息后推送给终端用户。白天推送量大每天都有早高峰和晚高峰夜间几乎没有流量。核心逻辑大概长这样// 初始配置核心线程4最大线程10队列容量500 ThreadPoolExecutor pushExecutor new ThreadPoolExecutor( 4, 10, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(500), new NamedThreadFactory(push-worker), new ThreadPoolExecutor.CallerRunsPolicy() );早上8点开始流量慢慢上来监控发现队列积压从几十涨到了两百多活跃线程数稳定在8~9个说明核心线程明显不够了。这时候我们通过配置中心下发调整指令把核心线程从4调到了8最大线程从10调到了12队列保持500不变。改完之后积压很快被打消CPU使用率也从45%涨到了65%不过还在安全范围。晚上10点流量开始下降队列几乎清空活跃线程数下滑到了2~3个。再把核心线程从8调回4最大线程从12调回8同时开启 allowCoreThreadTimeOut(true)让空闲的核心线程也能在超时后回收。第二天早上起来看内存占用明显下降了一个量级。实际操作下来动态调整最大的收益并不是性能提升多少倍而是让服务在流量变化时保持稳定同时减少不必要的资源占用。改一次参数就能省下的内存和CPU可能不多但持续一个月、一个季度下来效果很明显。6. 常见问题与踩坑实录6.1 Executors 内置线程池的问题网上关于 Executors 的批判已经很多了我简单总结一下实际踩过的坑newFixedThreadPool / newSingleThreadExecutor默认用无界 LinkedBlockingQueue任务积压导致内存飙升最终 OOM。newCachedThreadPool最大线程数是 Integer.MAX_VALUE如果任务提交速度长期快于处理速度会创建大量线程直接打崩系统和数据库连接池。newScheduledThreadPool最大线程数也是 Integer.MAX_VALUE同样有无限创建线程的风险。除非你明确知道自己要什么否则在生产环境一律不用 Executors 的快捷方法。6.2 任务耗时过长怎么办如果线程池里跑的任务执行时间远超预期线程长期不释放核心参数再怎么调都救不了。这种问题要从上游解决优化任务逻辑、拆分大任务、减少对慢外部接口的同步依赖或者给任务设置超时。我碰到过一个最离谱的案例一个业务方把大批量文件导入操作放到了共享线程池里执行一个任务要跑20多分钟直接把所有工作线程都占住了其他业务的短任务全部排队。这个问题最终是靠拆任务解决的把一次大导入拆成多个小批任务每批几百条数据执行完再提交下一批整个线程池的吞吐量反而提升了。6.3 线程命名不规范的坑排查问题的时候最痛苦的就是看到一堆pool-3-thread-1这种线程名根本不知道是哪个业务在用。自定义 ThreadFactory 很简单的但带来的排查收益非常高ThreadFactory factory new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread thread new Thread(r); thread.setName(order-async-worker- counter.getAndIncrement()); thread.setDaemon(false); thread.setUncaughtExceptionHandler((t, e) - log.error(线程 {} 执行异常, t.getName(), e)); return thread; } };用线程 dump 排查问题的时候一眼就能看出哪个线程池出问题了哪个业务线在占资源。这个习惯越早养成越好。6.4 常见问题速查表现象可能原因解决思路任务被拒绝并抛出异常队列满 线程数达上限调大队列或最大线程数考虑更换拒绝策略线程池队列积压持续增加处理能力跟不上提交速度增加核心线程数优化任务耗时检查上游突增流量内存占用持续升高无界队列积压任务改用有界队列调低队列容量加上监控告警线程数一直处于最大值任务执行耗时过长或流量过大分析任务耗时拆分任务合理调整最大线程数CPU 使用率接近 100%线程数过多上下文切换频繁降低核心线程数和最大线程数核心线程长期空闲占内存流量低但线程不回收开启 allowCoreThreadTimeOut(true) 或调小核心线程数shutdown 与 shutdownNow 的区别shutdown 是优雅关闭等所有已提交任务执行完再终止shutdownNow 是立刻中断所有线程返回还没执行的任务列表。线上要优雅停机一般用 shutdown 加上一段等待时间超时再强制结束。线程池隔离多个业务共用同一个线程池一个业务的慢任务可能拖垮另一个业务。重要业务应该拆分成独立的线程池单独配置参数。不要把线程池的生命周期交给Spring容器乱管如果使用 Bean 方式声明线程池要提供明确的 destroyMethod否则容器关闭时容易报错或者线程不被完整回收。7. 写在最后的一些经验线程池不是配置完就能一劳永逸的。我见过太多系统上线后从未回头看过线程池的运行情况直到出故障才去翻日志一问三不知连核心线程数和队列容量都答不上来。这是个很可怕的状态。我个人比较推荐的做法是每次上线前把线程池相关的监控指标都拉出来看一遍活跃线程数、队列占用率、最大耗时、拒绝次数按周、按月定期检查。流量模型不可能一成不变业务增长、接口变慢、下游服务改造都可能会影响线程池的行为。平时多花5分钟看看监控远好过故障时花5小时排查。说一个我自己的体会作为开发最该养成的习惯是把线程池的调整当成运维手段而不仅仅是编码工具。动态调整能力就是为此准备的。遇到流量高峰先改配置压住阵脚再慢慢优化代码逻辑最后再考虑是否需要永久调整参数。这比紧张地重发版本下线再改要有把握得多。最后再分享一个小技巧如果团队规模不大没有专门的监控平台可以写一个简单的定时任务把线程池的核心指标打印到日志里再用日志聚合工具收集。有了数据之后动态调整就不会变成拍脑袋。这个成本很低但收益直接对标线上稳定性。