1. 为什么我劝你别偷懒Exectors工具类里的隐形坑先讲个我自己的经历。早几年接手一个内部报表系统上游接口偶尔会突然慢几秒由于当时赶进度同事图省事创建线程池直接用Executors.newFixedThreadPool(8)任务提交用的是无界的LinkedBlockingQueue。表面看一切正常但线上有一次上游接口连续超时大量请求任务塞进队列导致内存持续上涨最后老年代占满触发频繁 Full GC。重启之后排查半天问题根源就是那个随手写下的线程池。那件事之后我给自己定了一条规矩线上代码里线程池一定要手动创建参数必须在代码里明确写出来更重要的是线程池里的线程必须要通过自定义ThreadFactory来命名和配置。这个习惯后来帮我省了无数次定位线上问题的力气。很多人初次接触线程池会先学Executors工具类因为确实太方便了ExecutorService pool Executors.newFixedThreadPool(5);但在实际项目中这套默认配置是远远不够的。它主要存在三个问题第一默认线程名没有业务信息。假设你的应用里同时有订单处理线程池、日志推送线程池、数据清洗线程池它们崩了或者卡住了打印出来的线程栈全长一个样pool-1-thread-1、pool-2-thread-3。你盯着日志完全分不清是哪条业务链路出的问题只能一个个去猜。第二默认线程不是守护线程。Executors内部用的是DefaultThreadFactory创建出来的线程是非守护线程。如果某些任务需要驻留后台轮询你希望 JVM 能正常退出但因为这个线程池里的线程还活着进程就退不掉。这在开发环境不明显在部署脚本和容器场景里非常容易踩中。第三newFixedThreadPool和newSingleThreadExecutor默认用了无界队列。任务可以无限堆积线程数却固定不变。一旦任务积压速度超过处理速度队列里的对象会一直积压轻则延迟飙升重则内存溢出。newCachedThreadPool则完全相反——最大线程数是Integer.MAX_VALUE任务一多就疯狂建线程直接把系统资源耗尽。所以这次这个 demo我们就彻底绕开Executors从构造器层面手动组装一个线程池再配一个自定义的ThreadFactory。这个组合拳几乎是所有中大型项目里最通用的做法看懂这个 demo以后看任何框架源码里的线程池配置都会觉得眼熟。2. 先把线程池的七个参数和ThreadFactory的原理掰开揉碎2.1 七个核心参数每一个都决定了线程池的生死ThreadPoolExecutor最完整的构造器长这样public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)逐个说清楚这七个参数缺一不可corePoolSize核心线程数线程池里常驻的线程数量。即使线程空闲默认也不会销毁除非设置了allowCoreThreadTimeOut(true)。可以理解成一家餐厅的固定员工不管忙不忙这几个人都在岗。maximumPoolSize最大线程数线程池最多能创建的线程数量。当核心线程全部忙碌且任务队列也满了线程池才会继续创建新线程直到达到这个上限。对应到餐厅就是高峰期临时叫来的兼职服务员的上限。keepAliveTime存活时间当线程数超过核心线程数时多余的空闲线程最多存活多久。如果超过这个时间还没有新任务进来这些额外的线程就会被回收。它只在“线程数大于核心线程数”的时候才有意义。unit时间单位keepAliveTime的时间单位一般用TimeUnit.SECONDS或TimeUnit.MINUTES。workQueue任务队列核心线程全部忙不过来的话新任务先放进队列等待。队列选型是最容易踩坑的地方LinkedBlockingQueue无界队列任务可以无限堆积不会触发 maximumPoolSize 扩容风险大ArrayBlockingQueue有界队列必须指定容量队列满了之后才触发扩容SynchronousQueue不存储任务直接把任务交给新线程适合任务处理速度极快的场景。threadFactory线程工厂这是本次 demo 的重头戏。它负责实际“生产”线程对象包括线程命名、优先级、是否守护线程、是否自定义异常处理器等。handler拒绝策略当任务队列已满线程数也达到上限新提交的任务就会被拒绝。四种内置拒绝策略如下策略行为适用场景AbortPolicy直接抛RejectedExecutionException默认策略希望立刻感知问题CallerRunsPolicy由提交任务的线程自己执行该任务不想丢弃任务且能容忍提交线程被阻塞DiscardPolicy静默丢弃新提交的任务允许丢失部分任务例如打点日志DiscardOldestPolicy丢弃队列里最旧的任务再尝试提交新的希望保留最新任务可容忍旧任务被丢弃2.2 ThreadFactory 源码到底做了什么直接看 JDK 自带的DefaultThreadFactory源码逻辑非常清晰public Thread newThread(Runnable r) { Thread t new Thread(group, r, namePrefix threadNumber.getAndIncrement(), 0); if (t.isDaemon()) t.setDaemon(false); // 强制设置非守护线程 if (t.getPriority() ! Thread.NORM_PRIORITY) t.setPriority(Thread.NORM_PRIORITY); // 统一设置标准优先级 return t; }JDK 默认实现里线程命名格式是pool-N-thread-MN 是线程池编号M 是这个池里的线程编号。这种命名最大问题就是——多业务共存时毫无辨识度。自定义ThreadFactory本质上就是重写这一个方法。我们只需要做三件事实现ThreadFactory接口在newThread(Runnable r)里创建Thread对象给线程取一个能一眼分辨出业务归属的名字并设置是否守护。来写第一版最简单的实现线程名带固定前缀加自增序号import java.util.concurrent.ThreadFactory; import java.util.concurrent.atomic.AtomicInteger; public class NamedThreadFactory implements ThreadFactory { private final String namePrefix; private final AtomicInteger threadNumber new AtomicInteger(1); public NamedThreadFactory(String namePrefix) { this.namePrefix namePrefix; } Override public Thread newThread(Runnable r) { Thread thread new Thread(r, namePrefix - threadNumber.getAndIncrement()); return thread; } }AtomicInteger保证多线程环境下序号自增是线程安全的不用加锁。namePrefix建议直接带上业务模块名例如order-async-pool、file-upload-pool。这样将来 jstack 查看线程栈时哪个业务线的线程一目了然。3. 自定义线程池demo从配置到运行的全过程3.1 demo 的思路与整体结构这个 demo 我设计了三个部分一个模拟耗时业务的任务类一个刚刚写好的NamedThreadFactory主程序里手动创建线程池提交一批任务并验证线程命名、拒绝策略和动态扩容的效果。同时我设置了一个偏小的队列ArrayBlockingQueue(3)核心线程 2 个最大线程 4 个故意制造“队列满员 线程扩容”的场景这样现象更直观。3.2 完整可运行的 demo 代码首先是模拟任务类每个任务打印当前执行线程的名称和任务编号然后睡 200 毫秒模拟业务处理import java.util.Date; public class DemoTask implements Runnable { private final int taskId; public DemoTask(int taskId) { this.taskId taskId; } Override public void run() { String threadName Thread.currentThread().getName(); System.out.printf(%s 任务ID%d 开始执行时间%s%n, threadName, taskId, new Date()); try { Thread.sleep(200); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.printf(%s 任务ID%d 执行完成%n, threadName, taskId); } }接着是核心的线程池配置与提交逻辑import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; public class ThreadPoolDemo { public static void main(String[] args) { // 1. 手动创建线程池绕开 Executors ThreadPoolExecutor executor new ThreadPoolExecutor( 2, // corePoolSize 4, // maximumPoolSize 10, // keepAliveTime TimeUnit.SECONDS, new ArrayBlockingQueue(3), // 有界队列容量3 new NamedThreadFactory(order-async-pool), // 自定义线程工厂 new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 ); // 2. 提交10个任务 for (int i 1; i 10; i) { executor.submit(new DemoTask(i)); } // 3. 关闭线程池 executor.shutdown(); try { // 最多等60秒 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { executor.shutdownNow(); } } catch (InterruptedException e) { executor.shutdownNow(); Thread.currentThread().interrupt(); } System.out.println(全部任务执行完毕); } }3.3 运行结果解析队列、扩容、拒绝策略是怎么协作的跑一次上面的 demo控制台会出现一大串order-async-pool-1和order-async-pool-2开头的日志。仔细观察会发现几件事第一并非所有任务都用到了新线程。前两个任务被核心线程 1 和 2 接走任务 3 到 5 进入容量为 3 的有界队列等待。这个阶段线程池没有扩容因为队列还没满。第二任务 6 到来时队列已满线程数开始往 max 增长。此时线程池创建了 3 号和 4 号线程取决于线程工厂已经编号到几任务 6 和 7 被新线程直接执行。这验证了ThreadPoolExecutor的一个关键规则先填核心线程再进队列队列满了才尝试扩容到 maxThreadNum。这里我用的是CallerRunsPolicy所以当任务 8、9、10 提交时活跃线程数已经达到最大 4、队列也满了再往池子里塞任务就会被拒绝策略接住。CallerRunsPolicy会把剩余任务交还给提交任务的 main 线程去执行所以运行日志里你还会看到main线程直接执行任务的现象而后面的任务处理时长也会因此变慢一些。这个现象很重要很多初次接触线程池的人会误以为“只要核心线程忙就会立刻建新线程”。实际上必须结合队列饱和度来判断队列没满时线程池是一副“忍让”的姿态只有队列满了才会继续扩大规模。为了验证线程池整体行为我把这 10 个任务的执行日志按顺序整理成了一张假想表方便你对照参数理解现象提交顺序当时状态被哪个线程执行任务1核心线程空闲order-async-pool-1任务2核心线程空闲order-async-pool-2任务3-5核心线程忙队列未满进入队列等待任务6-7队列已满线程未到上限扩容线程 order-async-pool-3/4任务8-10线程已满队列已满CallerRunsPolicy由 main 线程直接执行3.4 各种参数调整后的效果对比如果你有精力可以试着改变几个参数对比现象我建议至少试这么三组核心线程数改成 4最大线程数不变 4此时不会发生扩缩容任务 6 之前全部由核心线程处理多余任务全部排队队列换成LinkedBlockingQueue无界队列不会触发 3 号和 4 号线程创建任务 6-10 全部排队等待线程池永远不会达到 max 值拒绝策略换成AbortPolicy当任务 8 提交时会直接抛RejectedExecutionException后面的任务提交全部中断。每一项改动都能帮你加深对线程池参数协作的记忆。4. 线程命名和异常捕获ThreadFactory 在真实项目里到底能做什么4.1 线程名前缀排查线上故障的“指路牌”先说说命名这件事。你在线上遇到问题第一步往往是先抓线程栈。比如我用 jstack 打印出来的线程片段order-async-pool-1 prio5 Id12 RUNNABLE at com.demo.service.OrderService.process(OrderService.java:88)你一眼就知道这是订单异步池里的线程再往下翻个几行就能定位到具体的代码位置。而如果用的是默认命名pool-3-thread-1 prio5 Id12 RUNNABLE at com.demo.service.OrderService.process(OrderService.java:88)你得先去代码里搜索这个pool-3到底是哪段逻辑创建的线程池无形中增加了很多排查成本。我实际经历里最夸张的一次一个应用中有 9 个线程池全部长这样排查一个死锁问题花了整整一个下午。之后把所有线程池的命名规范化同类问题定位时间压缩到了十几分钟。所以ThreadFactory里最重要的一条实践就是命名前缀必须包含业务模块名 用途关键词。例如order-pay-notify-poolreport-export-async-poolmq-consume-pool同事一看就知道这个线程是干什么的出了事也知道往哪个模块方向查。4.2 设置守护线程解决 JVM 无法正常退出的坑自定义ThreadFactory还能顺手把线程设为守护线程。这里必须澄清一个概念守护线程不是“优先级更低的线程”它的核心特点是JVM 中只要还有非守护线程在运行JVM 就不会退出而当只剩下守护线程时JVM 会不管这些线程是否在执行任务直接退出。如果你的线程池是给后台定时任务用的比如某个轮询检查任务它常驻后台且不需要阻塞主流程退出就可以把线程设为守护线程。在NamedThreadFactory里加一行Thread thread new Thread(r, namePrefix - threadNumber.getAndIncrement()); thread.setDaemon(true);不过我要多提醒一句不要在需要异步持久化重要数据的场景里使用守护线程。比如你有一个异步写数据库的线程池主线程执行完正在退出如果线程池里的线程是守护线程JVM 会直接退出你的未落库数据就无声无息地丢了。这种场景应该保证线程是非守护的并且配合shutdown()awaitTermination()优雅关闭。4.3 自定义线程的异常处理避免异常被吞掉ThreadPoolExecutor里有个非常隐蔽的坑如果用execute()提交任务任务内部抛出的RuntimeException能打到控制台但你在外面根本没机会捕获它如果用submit()提交任务你拿到的是一个Future异常会被封装在Future里如果你不主动调用future.get()异常就会被静默吞掉。现实中大多数团队并没有养成“每次提交任务都记住拿返回值并调用 get()”的习惯于是线上任务挂了半天日志里什么都看不出来。自定义ThreadFactory可以在这里帮上大忙——创建线程时给线程挂一个UncaughtExceptionHandlerpublic Thread newThread(Runnable r) { Thread thread new Thread(r, namePrefix - threadNumber.getAndIncrement()); thread.setUncaughtExceptionHandler((t, e) - System.err.println(线程 t.getName() 抛出未捕获异常: e.getMessage())); return thread; }这样即使上层没有及时调用future.get()异常也会被统一记到某个日志通道不至于彻底失明。更规范的做法是把异常打印到统一日志文件里而不是System.err但 demo 里这一点足以说明思路。5. 参数选择与效果对比核心线程数、队列容量怎么定才靠谱5.1 任务类型决定线程池参数网上很多教程会把核心线程数的计算公式吹得神乎其神什么 CPU 密集型就CPU核数 1IO 密集型就CPU核数 * 2。我个人的经验是这些公式只能当作起步值绝对不能当作最终答案。实际项目里需要先分清楚任务类型CPU 密集型任务比如图像处理、加解密、大规模计算。这类任务占满 CPU线程太多反而因为上下文切换导致性能下降初始值可以设为CPU核数 1然后压测再调整。IO 密集型任务比如调用外部接口、读写数据库、传输文件。线程大部分时间在等待 IOCPU 比较闲线程数可以设大一些比如CPU核数 * 2作为起点再往上试探。混合型任务两个线程池分开跑更合理一个池处理 CPU 密集部分一个池处理 IO 密集部分避免互相拖累。不过我更推崇的实际做法是确定一个保守的初始参数然后通过压测观察线程池活跃线程数、队列积压量、任务处理时延这三个指标再反复调整到合适值。没有压测数据支撑的线程池参数都是拍脑袋。5.2 队列容量和使用场景的关系队列选型这块我认为最核心的判断标准是你能否接受任务积压带来的一系列连锁反应。如果你要求“任务一个都不能丢可以接受排队延迟”选有界队列容量给一个合理上限比如几百到几千结合任务堆积速度来定如果你希望“来了就立刻处理不要排队等待”可以考虑SynchronousQueue它不存任务线程数会快速拉高如果你明确知道偶尔的任务积压可接受但绝不能因为积压拖垮 JVM那ArrayBlockingQueue是稳妥选择配合一个合理的拒绝策略兜底。我见过不少团队把队列容量设置成 Integer.MAX_VALUE理由居然是“怕任务被拒绝”。这种做法等于把内存风险无限放大一旦流量尖峰出现最先挂的往往是 JVM。5.3 合理兜底手动拒绝策略通常会怎么做内置的CallerRunsPolicy在 demo 里用起来很直观但它也不是万能的。如果提交任务的线程本身处理任务会拖慢主链路甚至引发连环阻塞那就得考虑更保守的方案。实际项目中比较通用的做法是重写RejectedExecutionHandler把被拒绝的任务写进本地文件或消息队列稍后再补偿重放。比如public class CustomRejectedHandler implements RejectedExecutionHandler { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 将任务序列化后写入补偿表或文件 System.err.println(任务被拒绝进入补偿处理: r.toString()); } }不过这个方案要视具体业务而定核心精神是被拒绝不能意味着任务永久丢失至少要留下可恢复的线索。6. 进阶嵌套命名、优雅关闭和容器环境里的线程池特别注意点6.1 线程池里再建线程池的命名连贯性问题业务复杂了之后会遇到一种情况线程池的任务里又需要提交子任务到另一个线程池。比如订单处理线程池里的任务需要调用一个内部异步发送消息的线程池。这时候如果两个池分别命名为order-process-pool和order-msg-push-pool是基本要求。更进一步你可以在处理类的toString()或日志上下文里带上父线程名称这样从日志里能完整还原调用链public class AuditTask implements Runnable { Override public void run() { String lineage Thread.currentThread().getName(); // 父线程名 // 提交子任务时可以把 lineage 一起传入 } }6.2 shutdown、shutdownNow、awaitTermination 的正确用法线上很多故障都是线程池关闭方式不当造成的。我在这里分享一套相对稳妥的标准流程// 第一阶段停止接收新任务等待已提交任务执行完 executor.shutdown(); // 第二阶段给一个合理的等待时间比如30秒 if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { // 超时说明还有任务没执行完强制中断 executor.shutdownNow(); // 再等一小段时间确认线程全部退出 if (!executor.awaitTermination(5, TimeUnit.SECONDS)) { System.err.println(线程池未能完全停止); } }值得留意的是shutdownNow()并非魔法子弹。它会给正在跑的线程发中断信号但线程如果不响应中断依然会继续执行。而且shutdownNow()会返回一个ListRunnable里面是被取消但没执行的任务你可以把这些任务保存下来之后补偿重放。6.3 Spring 环境里别自己管线程池生命周期如果你在框架项目里开发比如常用的 Spring Boot那还有一条额外的建议把自定义线程池声明成一个容器管理的 Bean并实现DisposableBean或者配合PreDestroy调用关闭方法让容器帮你统一管理生命周期。业务代码里每次直接new ThreadPoolExecutor(...)是实践中的坏味道它会带来两个问题线程池对象散落在各个业务类里资源无法统一管理容器关闭时没有人负责优雅关停任务容易丢失。一个简单的 Spring 配置 Bean 大概长这样Configuration public class ThreadPoolConfig { Bean(orderAsyncExecutor) public ThreadPoolExecutor orderAsyncExecutor() { ThreadPoolExecutor executor new ThreadPoolExecutor( 4, 8, 30, TimeUnit.SECONDS, new ArrayBlockingQueue(500), new NamedThreadFactory(order-async-pool), new ThreadPoolExecutor.CallerRunsPolicy() ); return executor; } }也可以补充一个PreDestroy方法在应用停止时执行第 6.2 节中的优雅关闭流程。这样开发和运维都省心很多。7. 我实际使用中积累的三条操作经验最后聊几个容易被人忽略的小细节算是我踩坑换来的经验。第一条谨慎给线程池的大小设置动态调节逻辑。有人喜欢根据队列积压量动态调整 corePoolSize 或 maximumPoolSize。虽然ThreadPoolExecutor提供了setCorePoolSize()和setMaximumPoolSize()方法但动态调参需要非常谨慎因为频繁扩容缩容是有代价的——线程创建和销毁都有开销而且参数突变容易引起任务分配不均。我在生产环境里更倾向于固定参数 合理的拒绝策略只在有充分压测数据时才考虑动态方案。第二条线程名一定要包含业务唯一标识。例如订单处理线程池可以用order-async-pool做前缀如果同一模块有多个池子最好区别到具体用途比如order-async-pool-pay、order-async-pool-refund。别嫌名字长当你需要根据线程名从几百行日志里筛选问题时每多一个信息词排查效率都翻倍。第三条监控线程池的活跃线程数和队列大小比调优参数更重要。很多线上问题并不是线程池参数设得“不对”而是业务量涨了或者上游变慢了你完全没有察觉。我现在的习惯是给每个线程池加监控指标至少包括核心线程数、活跃线程数、队列积压数、拒绝任务数。一旦队列积压数持续上涨说明消费能力跟不上生产速度这时候就该考虑是不是要去调参数而不是等系统报警了再仓促处理。关于自定义线程池和自定义ThreadFactory的完整思路到这儿就算讲透了。其实整件事的核心并不复杂手动指定七参数管好线程池的行为边界重写ThreadFactory管好线程的身份信息。这两个习惯一旦养成你会发现自己排查线上并发问题的速度明显上了一个台阶。
1. 为什么我劝你别偷懒Exectors工具类里的隐形坑先讲个我自己的经历。早几年接手一个内部报表系统上游接口偶尔会突然慢几秒由于当时赶进度同事图省事创建线程池直接用Executors.newFixedThreadPool(8)任务提交用的是无界的LinkedBlockingQueue。表面看一切正常但线上有一次上游接口连续超时大量请求任务塞进队列导致内存持续上涨最后老年代占满触发频繁 Full GC。重启之后排查半天问题根源就是那个随手写下的线程池。那件事之后我给自己定了一条规矩线上代码里线程池一定要手动创建参数必须在代码里明确写出来更重要的是线程池里的线程必须要通过自定义ThreadFactory来命名和配置。这个习惯后来帮我省了无数次定位线上问题的力气。很多人初次接触线程池会先学Executors工具类因为确实太方便了ExecutorService pool Executors.newFixedThreadPool(5);但在实际项目中这套默认配置是远远不够的。它主要存在三个问题第一默认线程名没有业务信息。假设你的应用里同时有订单处理线程池、日志推送线程池、数据清洗线程池它们崩了或者卡住了打印出来的线程栈全长一个样pool-1-thread-1、pool-2-thread-3。你盯着日志完全分不清是哪条业务链路出的问题只能一个个去猜。第二默认线程不是守护线程。Executors内部用的是DefaultThreadFactory创建出来的线程是非守护线程。如果某些任务需要驻留后台轮询你希望 JVM 能正常退出但因为这个线程池里的线程还活着进程就退不掉。这在开发环境不明显在部署脚本和容器场景里非常容易踩中。第三newFixedThreadPool和newSingleThreadExecutor默认用了无界队列。任务可以无限堆积线程数却固定不变。一旦任务积压速度超过处理速度队列里的对象会一直积压轻则延迟飙升重则内存溢出。newCachedThreadPool则完全相反——最大线程数是Integer.MAX_VALUE任务一多就疯狂建线程直接把系统资源耗尽。所以这次这个 demo我们就彻底绕开Executors从构造器层面手动组装一个线程池再配一个自定义的ThreadFactory。这个组合拳几乎是所有中大型项目里最通用的做法看懂这个 demo以后看任何框架源码里的线程池配置都会觉得眼熟。2. 先把线程池的七个参数和ThreadFactory的原理掰开揉碎2.1 七个核心参数每一个都决定了线程池的生死ThreadPoolExecutor最完整的构造器长这样public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)逐个说清楚这七个参数缺一不可corePoolSize核心线程数线程池里常驻的线程数量。即使线程空闲默认也不会销毁除非设置了allowCoreThreadTimeOut(true)。可以理解成一家餐厅的固定员工不管忙不忙这几个人都在岗。maximumPoolSize最大线程数线程池最多能创建的线程数量。当核心线程全部忙碌且任务队列也满了线程池才会继续创建新线程直到达到这个上限。对应到餐厅就是高峰期临时叫来的兼职服务员的上限。keepAliveTime存活时间当线程数超过核心线程数时多余的空闲线程最多存活多久。如果超过这个时间还没有新任务进来这些额外的线程就会被回收。它只在“线程数大于核心线程数”的时候才有意义。unit时间单位keepAliveTime的时间单位一般用TimeUnit.SECONDS或TimeUnit.MINUTES。workQueue任务队列核心线程全部忙不过来的话新任务先放进队列等待。队列选型是最容易踩坑的地方LinkedBlockingQueue无界队列任务可以无限堆积不会触发 maximumPoolSize 扩容风险大ArrayBlockingQueue有界队列必须指定容量队列满了之后才触发扩容SynchronousQueue不存储任务直接把任务交给新线程适合任务处理速度极快的场景。threadFactory线程工厂这是本次 demo 的重头戏。它负责实际“生产”线程对象包括线程命名、优先级、是否守护线程、是否自定义异常处理器等。handler拒绝策略当任务队列已满线程数也达到上限新提交的任务就会被拒绝。四种内置拒绝策略如下策略行为适用场景AbortPolicy直接抛RejectedExecutionException默认策略希望立刻感知问题CallerRunsPolicy由提交任务的线程自己执行该任务不想丢弃任务且能容忍提交线程被阻塞DiscardPolicy静默丢弃新提交的任务允许丢失部分任务例如打点日志DiscardOldestPolicy丢弃队列里最旧的任务再尝试提交新的希望保留最新任务可容忍旧任务被丢弃2.2 ThreadFactory 源码到底做了什么直接看 JDK 自带的DefaultThreadFactory源码逻辑非常清晰public Thread newThread(Runnable r) { Thread t new Thread(group, r, namePrefix threadNumber.getAndIncrement(), 0); if (t.isDaemon()) t.setDaemon(false); // 强制设置非守护线程 if (t.getPriority() ! Thread.NORM_PRIORITY) t.setPriority(Thread.NORM_PRIORITY); // 统一设置标准优先级 return t; }JDK 默认实现里线程命名格式是pool-N-thread-MN 是线程池编号M 是这个池里的线程编号。这种命名最大问题就是——多业务共存时毫无辨识度。自定义ThreadFactory本质上就是重写这一个方法。我们只需要做三件事实现ThreadFactory接口在newThread(Runnable r)里创建Thread对象给线程取一个能一眼分辨出业务归属的名字并设置是否守护。来写第一版最简单的实现线程名带固定前缀加自增序号import java.util.concurrent.ThreadFactory; import java.util.concurrent.atomic.AtomicInteger; public class NamedThreadFactory implements ThreadFactory { private final String namePrefix; private final AtomicInteger threadNumber new AtomicInteger(1); public NamedThreadFactory(String namePrefix) { this.namePrefix namePrefix; } Override public Thread newThread(Runnable r) { Thread thread new Thread(r, namePrefix - threadNumber.getAndIncrement()); return thread; } }AtomicInteger保证多线程环境下序号自增是线程安全的不用加锁。namePrefix建议直接带上业务模块名例如order-async-pool、file-upload-pool。这样将来 jstack 查看线程栈时哪个业务线的线程一目了然。3. 自定义线程池demo从配置到运行的全过程3.1 demo 的思路与整体结构这个 demo 我设计了三个部分一个模拟耗时业务的任务类一个刚刚写好的NamedThreadFactory主程序里手动创建线程池提交一批任务并验证线程命名、拒绝策略和动态扩容的效果。同时我设置了一个偏小的队列ArrayBlockingQueue(3)核心线程 2 个最大线程 4 个故意制造“队列满员 线程扩容”的场景这样现象更直观。3.2 完整可运行的 demo 代码首先是模拟任务类每个任务打印当前执行线程的名称和任务编号然后睡 200 毫秒模拟业务处理import java.util.Date; public class DemoTask implements Runnable { private final int taskId; public DemoTask(int taskId) { this.taskId taskId; } Override public void run() { String threadName Thread.currentThread().getName(); System.out.printf(%s 任务ID%d 开始执行时间%s%n, threadName, taskId, new Date()); try { Thread.sleep(200); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.printf(%s 任务ID%d 执行完成%n, threadName, taskId); } }接着是核心的线程池配置与提交逻辑import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; public class ThreadPoolDemo { public static void main(String[] args) { // 1. 手动创建线程池绕开 Executors ThreadPoolExecutor executor new ThreadPoolExecutor( 2, // corePoolSize 4, // maximumPoolSize 10, // keepAliveTime TimeUnit.SECONDS, new ArrayBlockingQueue(3), // 有界队列容量3 new NamedThreadFactory(order-async-pool), // 自定义线程工厂 new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 ); // 2. 提交10个任务 for (int i 1; i 10; i) { executor.submit(new DemoTask(i)); } // 3. 关闭线程池 executor.shutdown(); try { // 最多等60秒 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { executor.shutdownNow(); } } catch (InterruptedException e) { executor.shutdownNow(); Thread.currentThread().interrupt(); } System.out.println(全部任务执行完毕); } }3.3 运行结果解析队列、扩容、拒绝策略是怎么协作的跑一次上面的 demo控制台会出现一大串order-async-pool-1和order-async-pool-2开头的日志。仔细观察会发现几件事第一并非所有任务都用到了新线程。前两个任务被核心线程 1 和 2 接走任务 3 到 5 进入容量为 3 的有界队列等待。这个阶段线程池没有扩容因为队列还没满。第二任务 6 到来时队列已满线程数开始往 max 增长。此时线程池创建了 3 号和 4 号线程取决于线程工厂已经编号到几任务 6 和 7 被新线程直接执行。这验证了ThreadPoolExecutor的一个关键规则先填核心线程再进队列队列满了才尝试扩容到 maxThreadNum。这里我用的是CallerRunsPolicy所以当任务 8、9、10 提交时活跃线程数已经达到最大 4、队列也满了再往池子里塞任务就会被拒绝策略接住。CallerRunsPolicy会把剩余任务交还给提交任务的 main 线程去执行所以运行日志里你还会看到main线程直接执行任务的现象而后面的任务处理时长也会因此变慢一些。这个现象很重要很多初次接触线程池的人会误以为“只要核心线程忙就会立刻建新线程”。实际上必须结合队列饱和度来判断队列没满时线程池是一副“忍让”的姿态只有队列满了才会继续扩大规模。为了验证线程池整体行为我把这 10 个任务的执行日志按顺序整理成了一张假想表方便你对照参数理解现象提交顺序当时状态被哪个线程执行任务1核心线程空闲order-async-pool-1任务2核心线程空闲order-async-pool-2任务3-5核心线程忙队列未满进入队列等待任务6-7队列已满线程未到上限扩容线程 order-async-pool-3/4任务8-10线程已满队列已满CallerRunsPolicy由 main 线程直接执行3.4 各种参数调整后的效果对比如果你有精力可以试着改变几个参数对比现象我建议至少试这么三组核心线程数改成 4最大线程数不变 4此时不会发生扩缩容任务 6 之前全部由核心线程处理多余任务全部排队队列换成LinkedBlockingQueue无界队列不会触发 3 号和 4 号线程创建任务 6-10 全部排队等待线程池永远不会达到 max 值拒绝策略换成AbortPolicy当任务 8 提交时会直接抛RejectedExecutionException后面的任务提交全部中断。每一项改动都能帮你加深对线程池参数协作的记忆。4. 线程命名和异常捕获ThreadFactory 在真实项目里到底能做什么4.1 线程名前缀排查线上故障的“指路牌”先说说命名这件事。你在线上遇到问题第一步往往是先抓线程栈。比如我用 jstack 打印出来的线程片段order-async-pool-1 prio5 Id12 RUNNABLE at com.demo.service.OrderService.process(OrderService.java:88)你一眼就知道这是订单异步池里的线程再往下翻个几行就能定位到具体的代码位置。而如果用的是默认命名pool-3-thread-1 prio5 Id12 RUNNABLE at com.demo.service.OrderService.process(OrderService.java:88)你得先去代码里搜索这个pool-3到底是哪段逻辑创建的线程池无形中增加了很多排查成本。我实际经历里最夸张的一次一个应用中有 9 个线程池全部长这样排查一个死锁问题花了整整一个下午。之后把所有线程池的命名规范化同类问题定位时间压缩到了十几分钟。所以ThreadFactory里最重要的一条实践就是命名前缀必须包含业务模块名 用途关键词。例如order-pay-notify-poolreport-export-async-poolmq-consume-pool同事一看就知道这个线程是干什么的出了事也知道往哪个模块方向查。4.2 设置守护线程解决 JVM 无法正常退出的坑自定义ThreadFactory还能顺手把线程设为守护线程。这里必须澄清一个概念守护线程不是“优先级更低的线程”它的核心特点是JVM 中只要还有非守护线程在运行JVM 就不会退出而当只剩下守护线程时JVM 会不管这些线程是否在执行任务直接退出。如果你的线程池是给后台定时任务用的比如某个轮询检查任务它常驻后台且不需要阻塞主流程退出就可以把线程设为守护线程。在NamedThreadFactory里加一行Thread thread new Thread(r, namePrefix - threadNumber.getAndIncrement()); thread.setDaemon(true);不过我要多提醒一句不要在需要异步持久化重要数据的场景里使用守护线程。比如你有一个异步写数据库的线程池主线程执行完正在退出如果线程池里的线程是守护线程JVM 会直接退出你的未落库数据就无声无息地丢了。这种场景应该保证线程是非守护的并且配合shutdown()awaitTermination()优雅关闭。4.3 自定义线程的异常处理避免异常被吞掉ThreadPoolExecutor里有个非常隐蔽的坑如果用execute()提交任务任务内部抛出的RuntimeException能打到控制台但你在外面根本没机会捕获它如果用submit()提交任务你拿到的是一个Future异常会被封装在Future里如果你不主动调用future.get()异常就会被静默吞掉。现实中大多数团队并没有养成“每次提交任务都记住拿返回值并调用 get()”的习惯于是线上任务挂了半天日志里什么都看不出来。自定义ThreadFactory可以在这里帮上大忙——创建线程时给线程挂一个UncaughtExceptionHandlerpublic Thread newThread(Runnable r) { Thread thread new Thread(r, namePrefix - threadNumber.getAndIncrement()); thread.setUncaughtExceptionHandler((t, e) - System.err.println(线程 t.getName() 抛出未捕获异常: e.getMessage())); return thread; }这样即使上层没有及时调用future.get()异常也会被统一记到某个日志通道不至于彻底失明。更规范的做法是把异常打印到统一日志文件里而不是System.err但 demo 里这一点足以说明思路。5. 参数选择与效果对比核心线程数、队列容量怎么定才靠谱5.1 任务类型决定线程池参数网上很多教程会把核心线程数的计算公式吹得神乎其神什么 CPU 密集型就CPU核数 1IO 密集型就CPU核数 * 2。我个人的经验是这些公式只能当作起步值绝对不能当作最终答案。实际项目里需要先分清楚任务类型CPU 密集型任务比如图像处理、加解密、大规模计算。这类任务占满 CPU线程太多反而因为上下文切换导致性能下降初始值可以设为CPU核数 1然后压测再调整。IO 密集型任务比如调用外部接口、读写数据库、传输文件。线程大部分时间在等待 IOCPU 比较闲线程数可以设大一些比如CPU核数 * 2作为起点再往上试探。混合型任务两个线程池分开跑更合理一个池处理 CPU 密集部分一个池处理 IO 密集部分避免互相拖累。不过我更推崇的实际做法是确定一个保守的初始参数然后通过压测观察线程池活跃线程数、队列积压量、任务处理时延这三个指标再反复调整到合适值。没有压测数据支撑的线程池参数都是拍脑袋。5.2 队列容量和使用场景的关系队列选型这块我认为最核心的判断标准是你能否接受任务积压带来的一系列连锁反应。如果你要求“任务一个都不能丢可以接受排队延迟”选有界队列容量给一个合理上限比如几百到几千结合任务堆积速度来定如果你希望“来了就立刻处理不要排队等待”可以考虑SynchronousQueue它不存任务线程数会快速拉高如果你明确知道偶尔的任务积压可接受但绝不能因为积压拖垮 JVM那ArrayBlockingQueue是稳妥选择配合一个合理的拒绝策略兜底。我见过不少团队把队列容量设置成 Integer.MAX_VALUE理由居然是“怕任务被拒绝”。这种做法等于把内存风险无限放大一旦流量尖峰出现最先挂的往往是 JVM。5.3 合理兜底手动拒绝策略通常会怎么做内置的CallerRunsPolicy在 demo 里用起来很直观但它也不是万能的。如果提交任务的线程本身处理任务会拖慢主链路甚至引发连环阻塞那就得考虑更保守的方案。实际项目中比较通用的做法是重写RejectedExecutionHandler把被拒绝的任务写进本地文件或消息队列稍后再补偿重放。比如public class CustomRejectedHandler implements RejectedExecutionHandler { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 将任务序列化后写入补偿表或文件 System.err.println(任务被拒绝进入补偿处理: r.toString()); } }不过这个方案要视具体业务而定核心精神是被拒绝不能意味着任务永久丢失至少要留下可恢复的线索。6. 进阶嵌套命名、优雅关闭和容器环境里的线程池特别注意点6.1 线程池里再建线程池的命名连贯性问题业务复杂了之后会遇到一种情况线程池的任务里又需要提交子任务到另一个线程池。比如订单处理线程池里的任务需要调用一个内部异步发送消息的线程池。这时候如果两个池分别命名为order-process-pool和order-msg-push-pool是基本要求。更进一步你可以在处理类的toString()或日志上下文里带上父线程名称这样从日志里能完整还原调用链public class AuditTask implements Runnable { Override public void run() { String lineage Thread.currentThread().getName(); // 父线程名 // 提交子任务时可以把 lineage 一起传入 } }6.2 shutdown、shutdownNow、awaitTermination 的正确用法线上很多故障都是线程池关闭方式不当造成的。我在这里分享一套相对稳妥的标准流程// 第一阶段停止接收新任务等待已提交任务执行完 executor.shutdown(); // 第二阶段给一个合理的等待时间比如30秒 if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { // 超时说明还有任务没执行完强制中断 executor.shutdownNow(); // 再等一小段时间确认线程全部退出 if (!executor.awaitTermination(5, TimeUnit.SECONDS)) { System.err.println(线程池未能完全停止); } }值得留意的是shutdownNow()并非魔法子弹。它会给正在跑的线程发中断信号但线程如果不响应中断依然会继续执行。而且shutdownNow()会返回一个ListRunnable里面是被取消但没执行的任务你可以把这些任务保存下来之后补偿重放。6.3 Spring 环境里别自己管线程池生命周期如果你在框架项目里开发比如常用的 Spring Boot那还有一条额外的建议把自定义线程池声明成一个容器管理的 Bean并实现DisposableBean或者配合PreDestroy调用关闭方法让容器帮你统一管理生命周期。业务代码里每次直接new ThreadPoolExecutor(...)是实践中的坏味道它会带来两个问题线程池对象散落在各个业务类里资源无法统一管理容器关闭时没有人负责优雅关停任务容易丢失。一个简单的 Spring 配置 Bean 大概长这样Configuration public class ThreadPoolConfig { Bean(orderAsyncExecutor) public ThreadPoolExecutor orderAsyncExecutor() { ThreadPoolExecutor executor new ThreadPoolExecutor( 4, 8, 30, TimeUnit.SECONDS, new ArrayBlockingQueue(500), new NamedThreadFactory(order-async-pool), new ThreadPoolExecutor.CallerRunsPolicy() ); return executor; } }也可以补充一个PreDestroy方法在应用停止时执行第 6.2 节中的优雅关闭流程。这样开发和运维都省心很多。7. 我实际使用中积累的三条操作经验最后聊几个容易被人忽略的小细节算是我踩坑换来的经验。第一条谨慎给线程池的大小设置动态调节逻辑。有人喜欢根据队列积压量动态调整 corePoolSize 或 maximumPoolSize。虽然ThreadPoolExecutor提供了setCorePoolSize()和setMaximumPoolSize()方法但动态调参需要非常谨慎因为频繁扩容缩容是有代价的——线程创建和销毁都有开销而且参数突变容易引起任务分配不均。我在生产环境里更倾向于固定参数 合理的拒绝策略只在有充分压测数据时才考虑动态方案。第二条线程名一定要包含业务唯一标识。例如订单处理线程池可以用order-async-pool做前缀如果同一模块有多个池子最好区别到具体用途比如order-async-pool-pay、order-async-pool-refund。别嫌名字长当你需要根据线程名从几百行日志里筛选问题时每多一个信息词排查效率都翻倍。第三条监控线程池的活跃线程数和队列大小比调优参数更重要。很多线上问题并不是线程池参数设得“不对”而是业务量涨了或者上游变慢了你完全没有察觉。我现在的习惯是给每个线程池加监控指标至少包括核心线程数、活跃线程数、队列积压数、拒绝任务数。一旦队列积压数持续上涨说明消费能力跟不上生产速度这时候就该考虑是不是要去调参数而不是等系统报警了再仓促处理。关于自定义线程池和自定义ThreadFactory的完整思路到这儿就算讲透了。其实整件事的核心并不复杂手动指定七参数管好线程池的行为边界重写ThreadFactory管好线程的身份信息。这两个习惯一旦养成你会发现自己排查线上并发问题的速度明显上了一个台阶。
