先说个真实感受：线程池这玩意儿，几乎每个Java项目都在用，但真能把它讲透的人不多。很多人是"会用"——new一个FixedThreadPool，往里丢任务，完事。但一旦遇到线上线程暴涨、任务堆积、拒绝异常、或者面试官问一句"线程池的原理是什么"，就露怯了。我见过太多简历写着"精通并发编程"，结果连ThreadPoolExecutor的execute()流程都说不清的候选人。
这篇文章不打算写那种教科书式的长篇大论，就按我这些年调优和面试的经验，把线程池的原理、参数配置、实际踩过的坑、以及面试里真正会考的考点，一次性理清楚。无论你是刚入门想搞懂基础，还是工作几年想补一补盲区，这篇应该都能对得上胃口。
1. 线程池的核心逻辑：从"怎么回事"讲起
1.1 为什么要线程池：裸线程的三宗罪
早年间写多线程程序，最简单的做法就是new Thread()然后start()。今天写业务代码如果还在这么干，基本属于给自己埋雷。三个最要命的问题：
第一是线程的创建和销毁开销不可忽略。JVM创建一个线程，需要分配独立的栈空间（默认1MB左右），还要经过系统调用让操作系统来完成线程调度实体的创建。虽然现在线程创建不像早期的进程那么重，但高并发下频繁创建销毁，光是上下文切换和内存分配就能把性能拖垮。
第二是线程数量失控。假设你的接口并发峰值是2000，每个请求都new一个线程去跑，瞬间就产生2000个线程。一旦下游服务慢一点，请求继续堆积，线程数继续膨胀，最后把内存耗尽，直接OutOfMemoryError。这是裸线程方案最典型的死法。
第三是线程生命周期管理缺失。线程执行完毕就销毁，无法复用；异常如何处理、任务超时怎么控制、怎么优雅地关闭所有线程，全部要自己写。写出来的代码往往又长又难维护。线程池解决的就是这三个问题：复用线程、限制数量、统一管理生命周期。
用个生活化的比喻：一个银行网点如果来一个客户就安排一个柜员，客户走了柜员就离职，高峰期直接雇几千人，这种网点第二天就得倒闭。线程池就是那个"柜员不裁员、客户排队叫号"的方案——柜员就那几个，来了任务进队列排队，有空闲柜员就处理一个。
1.2 ThreadPoolExecutor运转机制：七个零件怎么配合
Java的线程池核心类就是ThreadPoolExecutor，它内部是一个典型的生产者-消费者模型。你可以把整个运行机制拆成七个关键零件：核心线程数（corePoolSize）、最大线程数（maximumPoolSize）、空闲存活时间（keepAliveTime）、时间单位（unit）、工作队列（workQueue）、线程工厂（threadFactory）、拒绝策略（handler）。
光说参数很枯燥，更重要的是理解提交一个任务后，ThreadPoolExecutor内部是怎么一步步处理的。整个流程是这样的：
- 提交任务到线程池。
- 判断当前工作线程数是否小于核心线程数。如果小于，直接创建一个新线程来执行这个任务（即使有空闲线程，也会先创建核心线程，这一点很多人理解错）。
- 如果核心线程已满，任务就会尝试放进工作队列（workQueue）等待。
- 如果队列也满了，再判断当前线程数是否小于最大线程数。如果小于，继续创建新线程（这里的"继续创建"就是非核心线程）。
- 如果线程数已经达到最大值，只能走拒绝策略处理器，按预先配置的策略处理这个任务。
这段流程用文字描述看着不长，但它决定了线程池行为的每一个细节。举几个容易错的场景：
场景一：核心线程数为1，最大线程数为5，队列大小为10，此刻池里只有一个线程，同时来20个任务，会怎样？答案是：第1个任务直接创建核心线程执行，接下来9个任务进入队列（注意这里不会创建非核心线程，因为队列还没满），第11个任务到来时队列已满，开始创建非核心线程（最多还能创建4个），第15个任务进来时线程数已达最大，队列也满，开始触发拒绝策略，第16~20个任务被拒绝。
场景二：核心线程数为0，最大线程数为5，队列大小为10，会怎样？答案完全不同：任务进来先尝试放入队列，而不是直接创建线程。如果队列没满，任务全在队列里，池里一个线程都没有。只有当队列满了，才会创建线程去消费。这就是为什么很多CachedThreadPool的行为让人困惑——它的核心线程就是0。
注意：核心线程数"创建新线程"这个动作，在任何时刻执行时都需要与线程池全局锁同步，所以线程池内部其实是有一个主锁（mainLock）来保护线程池状态的。
1.3 线程池的状态机：运行还是停止，有一套流程
线程池不只是一个简单的线程集合，它自己是有生命周期的。线程池内部维护了一个runState字段，用来表示当前线程池处于哪个状态。总共有五种状态：
- RUNNING：正常运行，能接收新任务，也能处理队列中的任务。
- SHUTDOWN：调用shutdown()方法进入，不再接收新任务，但会继续处理队列中已有的任务。
- STOP：调用shutdownNow()进入，不再接收新任务，不会处理队列中的任务，并且会中断正在执行的任务。
- TIDYING：所有任务已终止，且工作线程数为0时进入。这是一个过渡状态。
- TERMINATED：terminated()方法执行完毕后的最终状态。
五种状态之间不是随便跳的，它有一套流转规则：RUNNING可以转为SHUTDOWN或STOP；SHUTDOWN和STOP都可以转为TIDYING；TIDYING只能转为TERMINATED。这个状态机是线程池优雅关闭的基础，理解它才能搞清楚shutdown()和shutdownNow()的本质区别。
面试里常问一个变形题："线程池还能addWorker吗？"答案是要看状态：只有在RUNNING状态下，且线程数未达到上限时，addWorker才能成功。SHUTDOWN之后虽然不能添加新任务，但队列里已有的任务依然会被执行完成——这也是为什么有人说"shutdown之后还会跑一会儿"的原因。
2. 七大参数逐一拆解：每个参数背后都有说道
2.1 corePoolSize：核心线程数不是越大越好
核心线程数的字面意思是"线程池中常驻的工作线程数量"。当线程池刚刚创建时，并不会像很多人想的那样一下子创建好corePoolSize个线程——它是懒加载的，来一个任务才创建一个线程，直到数量达到corePoolSize。
这里有一个常被忽略的点：核心线程默认是"不会因为空闲而销毁"的。哪怕核心线程闲了几个月，它也会一直存活。但如果你在创建ThreadPoolExecutor之后调用了allowCoreThreadTimeOut(true)，核心线程也会因为超时而被回收。这个开关默认是false，很多人不知道。
那核心线程数怎么定？这是个没有标准答案的问题，但大致有一个经验范围：CPU密集型任务，核心线程数设置为CPU核心数+1；IO密集型任务，设置为CPU核心数乘以2。为什么是这个数？因为IO密集型的任务会大量等待磁盘或网络，在等待期间线程并不占用CPU，所以可以多开一些线程来把空闲出来的CPU时间填上。这个"经验值"只是起点，真实场景一定要压测验证。
2.2 maximumPoolSize：最大线程数的失控风险
最大线程数直接决定了线程池能创建的线程上限。前面说过，核心线程满了先去排队，队列满了才开始创建非核心线程。这句话反过来理解就是：如果你的队列是无界的（比如LinkedBlockingQueue默认容量是Integer.MAX_VALUE），那最大线程数形同虚设——因为队列永远不会满，永远走不到创建非核心线程这一步。
这是很多线上事故的根源。我见过一个真实案例：某服务用newFixedThreadPool(10)来异步处理消息，固定线程池用的就是无界队列。某天上游突然灌进来几十万条消息，线程池只有10个线程在消费，队列里攒了几十万个任务对象，每个任务对象还绑定了一堆数据库连接资源，最后直接内存溢出，把整个服务拖崩了。
设置最大线程数时一定要想清楚：当线程数达到最大值时，任务到底该怎么办？是丢弃？是让调用方自己跑？还是抛异常？这需要结合后面的拒绝策略一起考虑。
2.3 keepAliveTime：空闲回收的权衡
keepAliveTime和非核心线程的回收有关：当线程池中的线程数超过corePoolSize时（即有非核心线程存在），空闲时间超过keepAliveTime的线程会被回收。如果调用了allowCoreThreadTimeOut(true)，核心线程同样受这个时间控制。
这个参数值设多少，要看你的业务场景。如果是突发流量型业务，峰值来得快走得也快，keepAliveTime设短一点，比如30秒或60秒，让非核心线程赶紧消失，释放资源。如果业务流量一直很平稳，或者希望尽量复用线程，可以设长一些。最不推荐的就是设成0或非常短——这样非核心线程刚创建不久就被回收，下次流量一上来又要重新创建，起不到"池"的缓冲作用。
2.4 workQueue：队列选型决定行为边界
队列是线程池里最容易出幺蛾子的一个参数。常用的队列有四种：
- SynchronousQueue：不存储任务，每个插入操作必须等待另一个线程的移除操作。CachedThreadPool用的就是它。因为队列永远"满"，所以来一个任务就必须立刻创建一个线程去处理。如果线程数已达上限，立刻走拒绝策略。
- LinkedBlockingQueue：链表实现的有界或无界队列。默认无界，但你可以构造函数传入容量来限制。
- ArrayBlockingQueue：数组实现的有界队列，创建时必须指定容量。
- PriorityBlockingQueue：支持优先级排序的无界队列。
选队列的核心判断标准只有一个：队列要不要设容量上限、容量设多大。无界队列的优点是任务不会被拒绝，缺点是任务堆积可能导致内存暴涨，而且线程池的最大线程数基本废了。有界队列配合合理的容量，能有效控制资源占用，代价是可能会触发拒绝策略，所以你必须把拒绝策略想清楚。
我个人的经验是：业务系统里尽量不要用默认无界队列，除非你确定任务量永远在可控范围内。给队列设定一个明确的上限，相当于给系统加了一个"保险丝"，真出了问题最多是任务被拒，不至于整个进程挂掉。
2.5 threadFactory：给线程起名字是个好习惯
ThreadFactory是一个接口，只有一个方法newThread(Runnable r)。框架代码里如果不指定，默认工厂创建的线程名字是pool-x-thread-y，排查线上问题时日志里全是这种名字，根本分不清是哪个业务在跑。
自定义线程工厂最大的用处就是给线程起一个有辨识度的名字，比如"order-async-worker-1"。这样线程dump下来一眼就能看出来哪些线程是哪个业务池的。另一个常见的用法是在newThread方法里把线程设置为daemon线程（守护线程），这样JVM退出时不会因为线程池里的线程还活着而卡住退出流程。
这里要提醒一下：设置daemon线程要慎重，因为daemon线程里如果做的是关键异步任务（比如状态上报、事务消息），JVM退出时可能直接把它掐了，任务就丢了。大多数情况下还是让线程池里的线程作为普通线程运行，配合shutdown()优雅关闭更安全。
2.6 RejectedExecutionHandler：任务装不下了怎么办
当线程池饱和（线程数已达最大值且队列已满），新提交的任务会交给RejectedExecutionHandler处理。Java自带了四种策略：
- AbortPolicy：直接抛出RejectedExecutionException。这是默认策略，优点是能立刻暴露问题；缺点是没有降级，调用方必须自己捕获异常。
- CallerRunsPolicy：不抛异常，也不是丢弃，而是让提交任务的线程自己直接去执行这个任务。这个策略最"温柔"，相当于把多余的任务又扔回给调用方。用它最大的好处是不会丢任务，代价是调用方会被阻塞，变相实现了一种限流效果。
- DiscardPolicy：直接丢弃，不抛异常也不执行。说实话，生产环境用这个策略我是不太推荐的，任务被丢弃了你完全无感知。
- DiscardOldestPolicy：丢弃队列中最早的未处理任务，然后重新尝试提交当前任务。这个策略会导致先进入队列的任务可能永远不被处理，使用时需要评估"丢旧任务"是否符合业务语义。
还有一个思考方向：实际项目中很多团队不用内置策略，而是自定义handler，把被拒绝的任务转发到其他队列或者做降级上报。这种定制方案的效果往往比内置策略更好，因为它让"批量处理失败"这件事变得可见、可追踪。
提示：拒绝策略触发时，任务并没有真正执行。如果你要保证任务不丢，只能自己做好兜底，比如存库后重试。没有哪个内置策略能做到既全部执行又不会堆积，这不现实。
3. 线程池大小怎么算：不是拍脑袋，要讲证据
3.1 CPU密集型和IO密集型的黄金法则
线程池大小估算在业界流传着两个公式：
CPU密集型任务：corePoolSize = CPU核心数 + 1。为什么加1？因为即使是在CPU密集型场景下，也总有一个线程可能因为缺页、GC或其他原因短暂让出CPU，多一个线程能把这段空隙利用起来。
IO密集型任务：corePoolSize = CPU核心数 * 2（或者更多）。这个公式的底层逻辑是IO密集型任务的大部分时间都在等待，如果线程数跟CPU核心数一样多，那么在等待IO期间，CPU是闲置的。乘2是简单粗暴地增加"等待期的重叠度"。
更精细的公式来自布赖恩·格茨（Brian Goetz）在《Java并发编程实战》中提出的估算方法：
线程数 = CPU核心数 * (1 + 等待时间 / 计算时间)这个公式里最关键的是"等待时间/计算时间"的比例。如果一个任务里，计算耗时10ms，IO等待耗时90ms，那么比例就是9，理论上线程数可以开到CPU核心数乘以10。注意这只是理论值，只能用来定初始值，最终还是要靠压测不断校准。
3.2 用实例算一遍：两段场景拿计算器按出来的结果
场景一：一个纯计算任务，做图像特征提取，没有外部调用，每张图处理120ms，服务器是4核。
等待时间基本为0，所以：
线程数 ≈ 4 * (1 + 0/120) = 4考虑一点余量，可以取5。开多了反而会因为上下文切换导致总吞吐量下降。
场景二：一个接口任务，需要查数据库、调远程服务、再写回缓存。平均每个任务CPU计算耗时20ms，外部IO等待耗时180ms，服务器还是4核。
线程数 ≈ 4 * (1 + 180/20) = 4 * 10 = 40看到没？同样是4核机器，IO密集和CPU密集的答案能差出8倍。这就是为什么很多团队直接把corePoolSize写死成8或16，结果跑起来要么CPU飙高，要么任务排队严重，就是因为没有按任务类型区分。
3.3 压测才是最终裁判
公式只是给你一个起点。真实系统里任务耗时不是恒定的——GC暂停、网络抖动、数据库连接池打满，都会让"等待时间/计算时间"这个比例发生波动。所以我建议的做法是：先用公式算一个初始值，压测环境跑一轮，观察几个核心指标。
第一个看CPU使用率：如果线程池跑满时CPU只有30%，说明线程开少了，加大线程数还有提升空间；如果CPU一直100%而且线程还在增加，那就是线程开多了，上下文切换会让系统吞吐量不升反降。
第二个看队列积压量：如果任务积压持续增长，说明线程池处理速度低于提交速度，要么加线程，要么加机器，要么优化单任务耗时。
第三个看RT（响应时间）：有时候单个任务变慢不是线程池的问题，而是数据库、缓存、远程服务的瓶颈。线程池只是把下游的慢放大了，这时候盲目加线程只会让下游更慢。
记住：调线程池参数永远是一个"调优-观察-再调优"的迭代过程，没有任何一组参数能一劳永逸。
4. 实战中的避坑手册：这些坑我替你踩过了
4.1 全局线程池的复用：别再每次请求都new一个池
我在代码评审里见过无数次这种写法：方法内部需要异步执行一段逻辑，就直接new一个FixedThreadPool，用完再shutdown。这在低并发场景下看不出问题，一旦并发量上来，每个请求都创建和销毁一套线程池，性能开销甚至比裸线程还大，线程池本身的管理成本也被你吃掉了。
正确的做法是把线程池定义成Spring Bean或者静态变量，整个应用共享一个或者按业务域划分几个专用的线程池。比如订单模块一个、消息推送一个、报表导出一个，互不干扰。这样每个池的参数可以做差异化配置，也能分别监控。
但这里也有一个度的把握：全局只有一个线程池也未必好。不同类型的任务如果混在一起，可能互相影响。比如IO密集型的下载任务和CPU密集型的计算任务放在同一个池里，一旦IO任务把队列占满，CPU计算任务也跟着被阻塞。合理的划分粒度是"业务域+任务类型"两个维度。
4.2 优雅关闭线程池：shutdown和shutdownNow怎么选
线程池在应用关闭时如果不做处理，可能会导致任务丢失或者应用退出被阻塞。最常用的关闭方式是调用shutdown()方法——它会等待队列中的任务执行完毕才终止线程池。如果你希望立即终止，可以用shutdownNow()，它会尝试中断正在执行的任务，并返回排队中的任务列表供你处理。
实操里我写过一个比较稳妥的关闭流程：
ExecutorService executor = threadPool; executor.shutdown(); // 不再接受新任务 try { // 等待现有任务执行完毕，最多等30秒 if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { executor.shutdownNow(); // 超时后强制终止 if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { // 第二次强制终止后仍然没有退出，说明有任务无法响应中断 System.err.println("线程池未能完全终止"); } } } catch (InterruptedException e) { executor.shutdownNow(); Thread.currentThread().interrupt(); }这个流程的关键在于"先温柔后强制"：先给正常任务一个宽限期，超时之后才强制终止。如果你用的是Spring，建议把线程池的关闭逻辑挂在对应的生命周期回调里，确保容器关闭时线程池能得到清理。
4.3 任务异常不会自动打印：submit和execute的区别
这是很多人都踩过的一个隐蔽坑。用execute(Runnable)提交任务时，如果任务内部抛出未捕获异常，ThreadPoolExecutor的Worker线程会把异常打印到控制台（准确说是通过Thread的UncaughtExceptionHandler处理），之后这个线程会被销毁重建。但用submit(Runnable)提交时，异常会被包装进Future对象里，如果你不调用future.get()，异常永远不会被打印出来，直接被吞掉。
项目里异步日志上报、异步数据推送这种"丢进去就不管"的场景，如果用的是submit，一旦任务里抛异常，你是在日志里什么都看不到的。查问题的时候简直像大海捞针。
两个选择：要么在任务内部自己包一层try-catch，至少把异常记到日志里；要么提交任务时拿到Future，异步调用get()来处理异常。我个人习惯是：fire-and-forget的任务用execute()并设置自定义UncaughtExceptionHandler，需要拿到执行结果的用submit()并确保后续会调用get()。
4.4 线程池与ThreadLocal：小心把值串了
因为线程池里的线程是复用的，ThreadLocal的值如果不清理，会在线程之间"串味"。比如你用ThreadLocal存了当前请求的用户ID，如果这个线程之前处理过用户A的请求，线程被复用后可能还残留着用户A的ID，处理用户B的请求时一不小心就读到了旧值。
正确做法是每次任务执行完，在finally块里调用remove()清理ThreadLocal。更简单的方式是使用类似阿里的TransmittableThreadLocal这样的框架来在线程池场景下正确传递和清理上下文，不过那是另一个话题了，这里不展开。
4.5 动态调整参数：生产环境看不见的救命手段
ThreadPoolExecutor自带了一个方法叫setCorePoolSize和setMaximumPoolSize，这两个方法可以在运行期动态修改线程数。这意味着你可以在运行时通过监控接口或配置中心来调整线程池大小，而无需重启应用。
这个能力的实战价值很大：线上某个线程池突然任务积压了，你不想重启服务，就可以临时调大最大线程数和队列容量来顶住压力。当然这只是应急手段，根本解决还是需要分析任务为什么变慢。
不过要注意一点：setMaximumPoolSize不能设得比当前线程数还小，否则那些多出来的线程会在线程空闲后被回收。另外，动态调整时要结合"先加队列再加线程"的策略，避免突然增加线程导致下游被瞬时放大流量打崩。
5. 面试全考点：这些问题90%的候选人都答不完整
5.1 execute和submit到底差在哪
这是最经典的入门题。execute(Runnable)返回值是void，无法获取执行结果，也无法感知任务是否执行成功。submit(Callable)返回Future对象，可以获取结果、也可以捕获任务中的异常。很多候选人能答出这一点，但问深入一点"闲时线程池用execute和submit在异常处理上有什么区别"，大部分人就开始含糊了。
加餐知识点：execute提交的任务如果抛出运行时异常，线程会直接终结，线程池会新建一个线程补上。submit提交的任务异常会被保存在Future里，线程本身不受影响，不会重建。
5.2 线程数如何选择：除了CPU核心数还考虑什么
面试官喜欢问这个问题，更多是想考察你对"线程池调优不只是看CPU"这个点有没有认知。除了计算和IO比例之外，还要考虑：任务本身的优先级是否不同，是否需要设置优先级队列；线程池所在的JVM内存大小，因为每个线程要占用栈空间；下游服务能承受的并发上限，线程池的吞吐上限受限于最慢的那个环节；以及业务对RT（响应时间）和吞吐量哪个更敏感。
所以面试时不要只丢出一个公式，最好把思路串起来：先分类任务类型，再估算等待/计算比例，再结合GC和下游压力压测，最后确定初始值并设置监控。这个过程说下来，面试官基本就满意了。
5.3 核心线程数为0时会发生什么
这道题是近几年面试里高频出现的"刁钻题"。核心线程数为0，最大线程数为N，有界队列容量为K。提交第一个任务时，因为工作线程数（0）小于核心线程数（0）这个条件根本不成立，任务直接尝试入队。假设队列没满，任务就躺在队列里，池里一个线程都没有。只有当队列满了，才会创建线程去处理队列里的任务。
这里最反直觉的是：并不是任务来了就立刻创建线程。所以你可能会看到"CachedThreadPool提交一个任务后，线程数却一直为0"的现象。CachedThreadPool的核心线程数是0，最大线程数是Integer.MAX_VALUE，队列是SynchronousQueue——它之所以来一个任务就创建一个线程，是因为SynchronousQueue不存任务，任务一来队列就"满"，直接触发创建非核心线程的逻辑。
如果面试官问到这个层面，记得主动把CachedThreadPool的队列类型说清楚：SynchronousQueue没有容量，它不是一个缓存队列，而是一个"交棒"的机制。
5.4 线程池的状态流转与拒绝策略的联动
让我再把状态机拎出来说一下。当线程池进入SHUTDOWN状态后，这时候如果还有新任务提交，不会进入队列也不会创建线程，而是直接走拒绝策略。这就带来一个细节：即使线程池的线程数和队列都远没到上限，SHUTDOWN状态下的提交也会被拒绝。很多候选人只记得"队列满+线程满才会拒绝"，忽略了关闭状态也会拒绝任务。
如果面试谈到这个，可以顺手把拒绝策略和shutdown的关系补一句：用shutdown()优雅关闭时，如果允许调用方在关闭状态继续提交任务，需要你自己在代码里判断异常并处理；更稳妥的做法是在提交任务前先判断线程池是否处于运行状态，或者干脆在服务停止时先切断消息入口。
5.5 按自定义规则拒绝：面试官想听你怎么设计
一个高质量的回答思路是这样的：继承RejectedExecutionHandler，在rejectedExecution方法里把任务持久化到本地消息表或者高性能队列，再通过另一个定时任务去补偿执行。这样即使线程池饱和，任务也不会真正丢失。再延伸一点：如果任务对实时性要求不高，还可以直接把多余的任务"延迟"到低峰期处理，变相削峰填谷。
这个思路的本质是"把拒绝看作一种正常流程而不是异常流程"。这样回答，面试官会觉得你不只是背了四种内置策略，而是真的思考过工程场景下的兜底方案。
6. 监控与运维：参数配好了不看就是白搭
6.1 核心指标怎么盯
线程池不是配好参数就完事，运行期的指标监控才是后续调优的依据。几个关键指标：
- activeCount：当前正在执行任务的工作线程数。
- poolSize：当前线程池中的线程总数。
- queue.size()：当前队列积压的任务数。
- completedTaskCount：累计完成任务数。
- largestPoolSize：线程池历史达到过的最大线程数，用来判断是否触发过扩容。
这些指标通过ThreadPoolExecutor暴露的方法就能拿到，接入到监控系统后主要用来做两件事：一是设置告警，比如队列积压超过阈值就报警；二是留作事故后的复盘依据，看看崩溃前队列到底积压了多少任务。
6.2 利用Hook方法处理任务上下文
ThreadPoolExecutor还提供了三个可覆写的方法：beforeExecute和afterExecute分别在任务执行前后被调用，可以用来埋点记录每个任务的执行时间；而terminated在线程池终止后被调用，可以在这里做一些资源清理或者日志输出。这三个Hook方法在开源框架里用得很多，比如很多RPC框架会在beforeExecute里设置线程上下文的Tracer信息，在afterExecute里清除。
如果你干活的公司对可观测性要求高，建议直接在项目里封装一个带钩子的线程池工具类，统一打印任务执行耗时、异常信息，会让排查问题省很多力气。
6.3 一次线上线程池打爆内存的复盘
最后分享一个真实踩坑案例。某项目用线程池异步处理导出任务，任务里要读取一个大文件并生成Excel。最开始用的固定线程池是4个线程，无界队列。某天运营部门一次性导入了上万条数据，每个导出任务还会查询关联的多张表并加载进内存，单个任务内存占用可以到几百MB。
结果就是：4个线程在处理出队任务时，队列里已经积压了上万个等待中的任务对象，每个对象持有一堆查询参数和上下文信息，堆内存迅速被打爆，直接OOM。
这个事故复盘下来有两个最致命的错误：一是用了无界队列，系统失去了自我保护能力；二是任务本身的资源开销大，但线程池对此完全无感知。事后把队列改成了有界容量500，并自定义拒绝策略把超出的任务写入本地文件由补偿任务处理，同时给每个导出任务加了一个独立的内存使用上限校验。这套组合改完之后，再也没有因为导出任务出过事。
经验总结很简单：线程池是一个调度工具，它不负责判断任务本身合不合理。任务设计得再重，线程池也拦不住内存溢出。你需要做的是在池子和任务之间加一道"安全阀"，让系统在极端情况下能优雅地降级，而不是直接崩溃。
线程池这个知识点，从原理到参数配置、从坑点到面试题，其实是一个闭环。很多人只盯着参数怎么调，忽略了底层状态流转；又有人只会背面试题，真上了线还是不知道怎么排查。把这两头串起来，才算真正吃透。我自己在实际排查问题中最深的体会是：线程池的报错信息往往不是最明显的那个，真正的问题藏在线程dump里——下次遇到线程池相关的问题，别急着改参数，先花十分钟看看线程栈，往往比乱试一通靠谱得多。
