Java线程池核心参数原理与生产级配置实践

1. 为什么你写的“异步”其实根本没异步？——从一个被忽略的线程模型说起

SpringBoot项目里写个@Async，加个@EnableAsync，再配个ThreadPoolTaskExecutor，很多人就觉得自己搞定了异步。结果一压测，接口RT不降反升，CPU打满，日志里全是RejectedExecutionException，后台任务像卡住一样半天不动。我去年帮某电商中台团队做性能复盘时，翻了三天代码才发现：他们所谓的“异步发送短信”，实际是用new Thread()在Controller里硬起线程，而那个被注释掉的executorService.submit()调用，早在三个月前就被开发同学误删了——因为“IDE提示未使用”。

这背后暴露的，不是配置问题，而是对Java线程模型和Spring任务执行机制的根本性误解。ExecutorService不是魔法开关，它是一套有明确生命周期、资源边界和调度策略的可控并发基础设施。你传进去一个Runnable，它不会自动帮你处理线程安全、异常捕获、拒绝策略、队列阻塞、资源回收这些事；它只负责按你设定的规则，把任务分发到线程池里去跑。而Spring的@Async，本质只是对ExecutorService的一层封装代理，底层依然依赖你配置的线程池实例。一旦你没理解corePoolSize和maxPoolSize之间的“弹性伸缩窗口”，没搞清LinkedBlockingQueue和SynchronousQueue在任务积压时的行为差异，甚至没意识到ThreadFactory里不设setDaemon(false)会导致应用无法正常退出——那你的“异步”就只是把同步阻塞，换成了更难排查的线程饥饿或内存泄漏。

这篇文章不讲Spring Boot自动配置的甜点，也不堆砌@EnableAsync的10种写法。我们就聚焦最原始、最可控、也最容易出错的方式：手写ExecutorService+Runnable。这是所有高级封装的底层基石，是你调试线程问题时最终要回溯到的现场。我会带你从零搭起一个真正可用的线程池，逐行解释每个参数背后的取舍逻辑，展示真实压测中任务堆积时的线程状态快照，告诉你怎么一眼看出是队列满了还是线程数不够，以及——当shutdown()被调用后，那些还在跑的Runnable到底去了哪里。

2. 线程池不是越大越好：5个核心参数的物理意义与计算依据

2.1 你配的corePoolSize=10，真的需要10个常驻线程吗？

corePoolSize常被简单理解为“最小线程数”，但它的准确含义是：线程池会维持至少这么多数量的活跃线程，即使它们当前空闲，也不会被回收（除非设置了allowCoreThreadTimeOut(true)）。关键在于“维持”二字——它不是启动时就创建10个，而是当任务提交进来，发现当前活跃线程数 <corePoolSize，才会新创建线程来执行。

举个实际例子：某支付回调服务，平均QPS 200，单次处理耗时80ms。理论并发需求 = 200 * 0.08 = 16。如果你配corePoolSize=10，意味着前10个请求会各自占用一个线程，第11个请求进来时，线程池发现活跃线程=10，等于corePoolSize，它不会立刻创建第11个线程，而是先把任务丢进工作队列。只有当队列也满了，才会创建新线程，直到达到maxPoolSize。

所以corePoolSize的本质，是你愿意为“常规流量”长期持有的线程资源成本。设太高，空闲线程白白占内存、抢CPU时间片；设太低，常规流量就得排队，响应延迟上升。我的经验公式是：
corePoolSize ≈ 平均并发请求数 × (1 ± 0.2)
其中±0.2是预留缓冲，避免毛刺流量直接打满队列。上面的例子，我通常会设为16~20，而不是拍脑袋的10或50。

2.2maxPoolSize不是兜底，而是熔断开关

maxPoolSize常被当作“最大能开多少线程”的保险丝，但它的触发条件非常苛刻：必须同时满足两个条件：(1) 当前活跃线程数 ≥corePoolSize；(2) 工作队列已满（queue.offer()返回false）。很多同学只记得第二条，忘了第一条，导致以为队列一满就扩容，结果发现线程数死活上不去。

这就引出了关键问题：队列满了，到底是该扩容线程，还是该拒绝任务？maxPoolSize就是这个决策点。如果你设maxPoolSize = corePoolSize，等于关闭了动态扩容能力，所有超额任务都会走拒绝策略。这在IO密集型场景（如调第三方API）往往是合理选择——因为线程大部分时间在等网络响应，多开线程并不能提升吞吐，反而加剧上下文切换。但在CPU密集型计算（如图像压缩、数据聚合），适当提高maxPoolSize，让CPU核心尽量吃饱，反而是更优解。

计算maxPoolSize，我参考的是服务器的物理CPU核心数。公式：
maxPoolSize = CPU核心数 × (1.5 ~ 2.0)
比如一台8核机器，maxPoolSize设12~16。超过这个数，CPU上下文切换开销会急剧上升，整体吞吐反而下降。我们曾在线上将maxPoolSize从32降到16，TP99延迟下降了37%，就是因为消除了无谓的线程争抢。

2.3 工作队列：LinkedBlockingQueue的温柔陷阱

Spring Boot默认用LinkedBlockingQueue，无参构造时容量是Integer.MAX_VALUE（约21亿）。这看起来很“安全”，实则是最大的隐患。当corePoolSize设得小，而流量突增时，所有任务都往这个几乎无限的队列里塞，线程池永远不触发扩容（因为队列永远不会满），结果就是：大量任务在队列里排队，等待一个永远忙不过来的线程去消费。系统看起来“没报错”，但用户请求全部超时，监控里线程数恒定在corePoolSize，而队列长度疯狂上涨——这就是典型的“温柔死亡”。

更危险的是内存。每个Runnable对象本身不大，但如果你的Runnable里持有大对象引用（比如一个10MB的图片字节数组），那队列里积压1000个，就是10GB内存。JVM直接OOM。

所以，必须显式指定队列容量。我的原则是：

• 队列容量 ≤corePoolSize × 期望最大排队时长 / 单任务平均耗时
  比如corePoolSize=20，单任务平均100ms，你希望最长排队2秒，那么队列容量 ≤ 20 × 2000 / 100 = 400。我通常再打个8折，设为320。

另外，SynchronousQueue值得特别关注。它没有容量，offer()永远返回false，相当于强制“有空闲线程就立刻执行，否则立刻扩容”。这非常适合任务到达率稳定、且你希望线程数严格跟随负载的场景。但要注意，如果maxPoolSize设得太小，它会立刻触发拒绝策略。

2.4keepAliveTime：空闲线程的“保质期”

keepAliveTime定义了非核心线程（即corePoolSize之外创建的线程）在空闲多久后会被回收。注意，它只对非核心线程生效。核心线程默认永驻，除非你调allowCoreThreadTimeOut(true)。

这个参数的价值，在于应对流量波峰波谷。比如某报表服务，白天QPS 500，晚上跌到50。如果maxPoolSize=100，白天用满，晚上却还留着100个线程，纯属浪费。设keepAliveTime=60s，意味着晚上流量下去后，60秒内没新任务，多余的90个线程就会自动销毁。

但这里有个坑：keepAliveTime的单位。很多同学写executor.setKeepAliveTime(60, TimeUnit.SECONDS)，看着没问题。但如果线程池刚创建，还没提交任何任务，此时getPoolSize()是0，getActiveCount()也是0，keepAliveTime根本没机会生效。它只在有线程被创建出来，又变为空闲时才开始计时。所以，不要指望它能“预热”或“冷启”，它纯粹是事后清理机制。

2.5 拒绝策略：系统崩溃前的最后一道闸门

当corePoolSize已满、队列已满、maxPoolSize也已达上限，新任务进来怎么办？这就是拒绝策略（RejectedExecutionHandler）的职责。JDK提供了4种内置策略，但生产环境我只推荐两种：

• CallerRunsPolicy：由提交任务的线程（通常是Web容器线程，如Tomcat的http-nio-8080-exec-xx）自己来执行这个任务。这相当于给上游施加压力，让它慢下来。好处是绝不丢失任务，坏处是可能拖垮Web容器线程池，导致HTTP请求大面积超时。适用于任务绝对不能丢，且上游有重试机制的场景（如订单创建后的库存扣减）。

• AbortPolicy（默认）：直接抛RejectedExecutionException。这是最“诚实”的策略——明确告诉调用方：“我处理不了，请你自己决定怎么办”。配合全局异常处理器，可以记录告警、降级为同步执行、或写入死信队列。我们所有核心服务都用这个，因为可观察性优于盲目执行。你知道哪里堵了，才能去优化；你不知道，只会让问题在黑暗中蔓延。

绝对要避开DiscardPolicy（静默丢弃）和DiscardOldestPolicy（丢弃队首）。前者让你的任务无声消失，后者可能把最重要的任务（比如刚进来的支付确认）给丢了。线上出过事故：某风控服务用DiscardOldestPolicy，结果高并发时把“拦截高风险交易”的任务丢掉了，放行了本该拒绝的欺诈订单。

3. 从零手写一个生产级线程池：配置、初始化与任务提交全流程

3.1 不依赖Spring Boot AutoConfig，手动构建ThreadPoolExecutor

Spring Boot的@ConfigurationProperties(prefix = "spring.task.execution")很方便，但过度封装会掩盖细节。下面这段代码，是我在线上所有关键服务中实际使用的线程池初始化模板，它绕过了所有自动配置，完全掌控每一个参数：

@Configuration public class AsyncTaskConfig { @Bean("orderProcessExecutor") public ExecutorService orderProcessExecutor() { // 1. 定义ThreadFactory：关键！设置线程名和守护状态 ThreadFactory threadFactory = new ThreadFactoryBuilder() .setNameFormat("order-process-pool-%d") .setDaemon(false) // 必须false！否则应用关闭时线程被杀，任务丢失 .build(); // 2. 创建有界队列：容量320，基于2.3节计算得出 BlockingQueue<Runnable> workQueue = new LinkedBlockingQueue<>(320); // 3. 构建ThreadPoolExecutor：所有参数显式声明 return new ThreadPoolExecutor( 20, // corePoolSize: 支付回调平均并发16，预留25%缓冲 40, // maxPoolSize: 8核服务器，8*1.5=12，但支付回调IO密集，设高些防网络抖动 60L, // keepAliveTime: 60秒，应对夜间低峰 TimeUnit.SECONDS, workQueue, threadFactory, new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：由调用线程执行，避免丢单 ); } }

注意几个硬性要求：

• setDaemon(false)：这是生死线。Spring Boot应用关闭时，会调用executor.shutdown()，然后等待所有任务完成。如果线程是daemon，JVM会直接退出，未完成任务永久丢失。
• 队列容量显式指定：绝不用new LinkedBlockingQueue<>()这种无参构造。
• 拒绝策略选CallerRunsPolicy：支付领域，订单不能丢，宁可让HTTP请求慢一点，也要保证最终一致性。

3.2Runnable任务的正确写法：不只是System.out.println

很多人写Runnable，就是把原来同步代码包一层：

// ❌ 错误示范：没处理异常，没日志，没监控 executor.submit(() -> { smsService.send(phone, content); // 这里抛异常，谁来捕获？ });

一个健壮的Runnable，必须包含三要素：异常兜底、可观测日志、业务指标埋点。这是我在某物流系统里沉淀的标准模板：

public class OrderConfirmTask implements Runnable { private final Long orderId; private final String logisticsNo; private final Logger logger = LoggerFactory.getLogger(OrderConfirmTask.class); private final MeterRegistry meterRegistry; // Micrometer指标注册器 public OrderConfirmTask(Long orderId, String logisticsNo, MeterRegistry meterRegistry) { this.orderId = orderId; this.logisticsNo = logisticsNo; this.meterRegistry = meterRegistry; } @Override public void run() { // 1. 开始计时 Timer.Sample sample = Timer.start(meterRegistry); try { // 2. 业务逻辑 logisticsService.confirmDelivery(orderId, logisticsNo); logger.info("Order confirm success. orderId={}, logisticsNo={}", orderId, logisticsNo); // 3. 记录成功指标 Counter.builder("order.confirm.success") .tag("type", "async") .register(meterRegistry) .increment(); } catch (Exception e) { // 4. 关键！必须捕获所有异常，否则线程会静默终止 logger.error("Order confirm failed. orderId={}, logisticsNo={}", orderId, logisticsNo, e); // 5. 记录失败指标和错误类型 Counter.builder("order.confirm.failure") .tag("type", "async") .tag("error", e.getClass().getSimpleName()) .register(meterRegistry) .increment(); // 6. 可选：失败后重试或告警 if (e instanceof TimeoutException) { alertService.send("订单确认超时", "orderId=" + orderId); } } finally { // 7. 结束计时 Timer.builder("order.confirm.duration") .tag("type", "async") .register(meterRegistry) .record(sample.stop()); } } }

为什么必须try-catch？因为Runnable.run()方法签名不抛受检异常，任何未捕获的RuntimeException都会导致线程终止，而线程池会默默创建一个新线程顶上。表面看一切正常，但你的业务逻辑已经中断，且没有任何日志。这就是“静默失败”，比直接报错更可怕。

3.3 提交任务的三种方式与适用场景

ExecutorService提供三种提交任务的方法，语义和返回值完全不同：

1. execute(Runnable command)：最基础，无返回值，不关心任务结果。适用于“发出去就不管”的场景，如日志上报、埋点统计。

   // ✅ 正确：日志异步化，不需要知道是否成功 logExecutor.execute(() -> logService.asyncWrite(logEntry));

2. submit(Runnable task)：返回Future<?>，你可以调用future.get()阻塞等待执行结束（但通常不这么做），或future.isDone()查询状态。适用于需要感知任务是否启动/结束，但不关心返回值的场景，如启动一个后台清理任务。

   // ✅ 正确：启动定时清理，后续可检查状态 Future<?> cleanupFuture = cleanupExecutor.submit(() -> cacheService.clearExpired()); // ... 之后某个时刻 if (cleanupFuture.isDone()) { logger.info("Cache cleanup finished"); }

3. submit(Callable<T> task)：返回Future<T>，future.get()能拿到Callable的返回值。这是唯一能获取异步任务执行结果的方式。适用于需要结果做后续判断的场景，如异步校验。

   // ✅ 正确：异步校验库存，根据结果决定是否扣减 Future<Boolean> stockCheckFuture = stockExecutor.submit(() -> inventoryService.checkStock(orderId, skuId, quantity) ); try { Boolean inStock = stockCheckFuture.get(3, TimeUnit.SECONDS); // 最多等3秒 if (Boolean.TRUE.equals(inStock)) { inventoryService.deductStock(orderId, skuId, quantity); } } catch (TimeoutException e) { logger.warn("Stock check timeout, fallback to sync check"); // 降级为同步校验 }

提示：future.get()是阻塞操作，务必设置超时时间！否则一个慢任务会卡住整个调用链。生产环境我一律要求get(timeout, unit)，绝不允许无参get()。

3.4 应用优雅关闭：shutdown()与awaitTermination()的黄金组合

Spring Boot应用关闭时，必须确保线程池里的任务执行完毕，否则数据不一致。这需要两步：

@Component public class AsyncTaskShutdownHook implements DisposableBean { @Autowired private ExecutorService orderProcessExecutor; @Override public void destroy() throws Exception { logger.info("Shutting down orderProcessExecutor..."); // 1. 停止接收新任务 orderProcessExecutor.shutdown(); try { // 2. 等待最多60秒，让已有任务完成 if (!orderProcessExecutor.awaitTermination(60, TimeUnit.SECONDS)) { logger.warn("Order process executor did not terminate in 60 seconds. Forcing shutdown."); // 3. 强制中断所有正在执行的任务（慎用！） orderProcessExecutor.shutdownNow(); // 4. 再等10秒，确保中断信号被响应 if (!orderProcessExecutor.awaitTermination(10, TimeUnit.SECONDS)) { logger.error("Order process executor still not terminated after forced shutdown."); } } } catch (InterruptedException e) { logger.error("Interrupted while waiting for orderProcessExecutor to terminate", e); // 恢复中断状态 Thread.currentThread().interrupt(); } } }

关键点解析：

• shutdown()：平滑关闭。不再接受新任务，但会继续执行队列里已有的任务和正在运行的任务。
• awaitTermination(timeout)：阻塞等待，直到所有任务完成，或超时。这是最关键的一步，给了任务“善终”的机会。
• shutdownNow()：强制关闭。尝试中断所有正在执行的任务，并清空队列，返回未执行的任务列表。仅在awaitTermination超时后作为兜底，因为中断可能破坏业务一致性（如中断一个数据库事务）。
• Thread.currentThread().interrupt()：如果等待过程被外部中断，必须恢复中断状态，这是Java线程协作的规范。

4. 真实压测与问题排查：从线程Dump到GC日志的全链路诊断

4.1 一次典型的“假死”故障复盘：队列积压的可视化证据

某次大促前压测，我们发现订单创建接口TP99从200ms飙升到3秒。线程池配置是core=20, max=40, queue=320。第一反应是线程不够，于是把max调到80，结果TP99更差了，达到5秒。

我们立刻抓取了线程Dump（jstack -l <pid> > threaddump.txt），用grep "order-process-pool"过滤，发现：

"order-process-pool-1" #25 prio=5 os_prio=0 tid=0x00007f8b4c0a1000 nid=0x1a waiting on condition [0x00007f8b3d7f9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2034) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

所有线程都卡在LinkedBlockingQueue.take()，说明它们都在等队列里有任务。再看队列长度：

# jstat -gc <pid> 1s 3 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT ... ... ... ... 10240.0 9876.5 204800.0 198765.2 45056.0 42100.5 5632.0 5200.1 1234 12.345 56 2.345 14.690

EU（Eden区使用量）持续95%以上，OU（老年代使用量）缓慢上涨，YGCT（Young GC耗时）飙升——这是典型的对象创建速率远超GC处理能力。根源找到了：队列里积压了上千个OrderConfirmTask，每个任务都持有一个logisticsNo字符串和orderIdLong对象，而LinkedBlockingQueue内部是一个Node链表，每个Node又包装了Runnable，内存开销巨大。

解决方案不是加线程，而是限流+降级：

• 在orderProcessExecutor.submit()前加Sentinel限流，QPS阈值设为200；
• 对非核心任务（如发送营销短信）降级为同步执行，或改用消息队列；
• 将队列容量从320砍到128，让CallerRunsPolicy更快触发，把压力反馈给上游。

调整后，TP99回落到250ms，且压测期间EU稳定在60%以下。

4.2 如何读懂线程Dump：5个必查字段

一份有效的线程Dump，不是全文搜索RUNNABLE，而是聚焦5个关键字段：

实战技巧：用jstack抓取后，先用grep "java.lang.Thread.State:" threaddump.txt | sort | uniq -c | sort -nr统计各状态线程数。如果BLOCKED线程数 > 5，立刻用grep -A 10 "BLOCKED" threaddump.txt看它们在等哪把锁。

4.3jstat三板斧：定位GC与内存瓶颈

当线程池表现异常，90%的问题根源在JVM内存。jstat是最快捷的诊断工具：

1. 看新生代是否撑不住：jstat -gc <pid> 1s
   关注EC(Eden Capacity)和EU(Eden Used)。如果EU/EC长期 > 80%，说明对象创建太快，Young GC频繁。此时应检查Runnable是否创建了过多临时对象（如new String()、list.stream().map().collect()）。

2. 看老年代是否在膨胀：jstat -gcold <pid>
   关注OC(Old Capacity)和OU(Old Used)。如果OU持续缓慢上涨，且FGC(Full GC)次数增加，说明有对象从年轻代晋升到了老年代，且没被回收。典型原因：Runnable里缓存了大对象（如byte[]），或ThreadLocal未清理。

3. 看GC是否成为瓶颈：jstat -gcutil <pid> 1s
   关注YGC(Young GC次数)和YGCT(Young GC总耗时)。如果YGCT/YGC平均值 > 50ms，说明每次GC都很重，可能需要调大-Xmn（新生代大小）。

注意：jstat输出的单位是KB，不是MB。EC=10240.0表示10MB。别被小数点迷惑。

4.4 常见问题速查表：症状、原因与修复方案

5. 超越Runnable：Callable与Future的进阶用法与避坑指南

5.1Future.get()的致命陷阱：你以为的“超时”，其实是“阻塞”

Future.get(long timeout, TimeUnit unit)看似安全，但它有一个隐藏行为：如果任务在超时时间内完成了，get()会立即返回结果；但如果任务在超时后才完成，get()会一直阻塞，直到任务完成。这意味着，你设了3秒超时，但任务实际耗时5秒，get()会卡5秒，而不是3秒后抛TimeoutException。

验证代码：

ExecutorService executor = Executors.newSingleThreadExecutor(); Future<String> future = executor.submit(() -> { Thread.sleep(5000); // 故意睡5秒 return "done"; }); try { String result = future.get(3, TimeUnit.SECONDS); // 这里会卡5秒！ System.out.println(result); } catch (TimeoutException e) { System.out.println("Timeout!"); // 这行永远不会执行 }

根本原因在于Future.get()的实现逻辑：它先检查任务是否完成，如果没完成，就进入wait(timeout)，而wait的超时是“最多等这么久”，不是“等这么久就放弃”。真正的超时控制，必须由你自己实现：

public static <T> T getWithTimeout(Future<T> future, long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException { long start = System.nanoTime(); long remaining = unit.toNanos(timeout); while (!future.isDone()) { if (remaining <= 0) { throw new TimeoutException(); } // 短暂等待，避免忙等 future.wait(100); long elapsed = System.nanoTime() - start; remaining = unit.toNanos(timeout) - elapsed; } return future.get(); // 此时isDone为true，get()不会阻塞 }

但更推荐的做法是：不要用Future.get()做业务逻辑的主干，而是用CompletableFuture。它提供了真正的异步非阻塞组合能力。

5.2CompletableFuture：告别Future.get()的终极方案

CompletableFuture是Java 8引入的真正异步编程模型，它解决了Future的所有痛点：

• 非阻塞等待：thenApply,thenAccept,thenCompose等方法，都是在任务完成后由线程池回调执行，无需get()。
• 组合编排：allOf,anyOf,runAfterBoth，轻松实现任务依赖、并行聚合。
• 异常传播：exceptionally,handle，统一处理异步链路上的任何异常。

以订单创建为例，传统写法：

// ❌ 串行阻塞，且异常难处理 Future<Order> createFuture = orderExecutor.submit(() -> orderService.create(orderDto)); Future<Inventory> inventoryFuture = inventoryExecutor.submit(() -> inventoryService.check(orderId)); Future<Sms> smsFuture = smsExecutor.submit(() -> smsService.send(orderId)); // 这里三个get()都是阻塞的！ Order order = createFuture.get(); Inventory inventory = inventoryFuture.get(); Sms sms = smsFuture.get();

用CompletableFuture重构：

// ✅ 真正异步，并行执行，异常自动传播 CompletableFuture<Order> createFuture = CompletableFuture .supplyAsync(() -> orderService.create(orderDto), orderExecutor); CompletableFuture<Inventory> inventoryFuture = CompletableFuture .supplyAsync(() -> inventoryService.check(orderId), inventoryExecutor); CompletableFuture<Sms> smsFuture = CompletableFuture .supplyAsync(() -> smsService.send(orderId), smsExecutor); // 并行等待所有完成 CompletableFuture.allOf(createFuture, inventoryFuture, smsFuture) .thenRun(() -> logger.info("All async tasks completed")) .exceptionally(throwable -> { logger.error("Async task failed", throwable); return null; });

supplyAsync的第二个参数就是你自定义的ExecutorService，完美复用我们前面配置的线程池。这才是现代Java异步的正确打开方式。

5.3ThreadLocal在异步线程池中的“幽灵泄漏”

ThreadLocal是线程级别的变量，常用于传递上下文（如TraceId、用户信息）。但在ExecutorService中，线程是复用的，ThreadLocal的值不会自动清除。如果一个Runnable往ThreadLocal里塞了Map，而下一个任务没清理，就会拿到上一个任务的脏数据。

更严重的是内存泄漏：ThreadLocal的Entry是WeakReference，但value是强引用。如果ThreadLocal本身被回收（如Spring Bean销毁），而线程池里的线程还活着，value就再也无法被GC，造成泄漏。

解决方案只有两个：

1. 主动清理：在Runnable的finally块里，调用threadLocal.remove()。
2. 避免使用：用参数传递代替ThreadLocal。比如把traceId作为Runnable的构造参数传入，而不是从MDC里取。

// ✅ 安全：参数传递，无状态 public class OrderTask implements Runnable { private final String traceId; private final Long orderId; public OrderTask(String traceId, Long orderId) { this.traceId = traceId; this.orderId = orderId; } @Override public void run() { // 使用traceId，不依赖MDC logger.info("[{}] Processing order {}", traceId, orderId); } }

这是我在线上所有服务中强制推行的规范。ThreadLocal就像一把双刃剑，用不好，轻则数据错乱，重则OOM。

6. 我的个人经验总结：线程池不是配置项，而是服务契约

写完这篇近六千字的实操笔记，我想说的最后一点，可能和所有技术文档都不同：线程池的每一个参数，都不是技术参数，而是你对上下游服务的承诺。

corePoolSize=20，意味着你向调用方承诺：“我至少能同时处理20个请求，不排队”。如果做不到，就是SLA违约。

queueCapacity=320，意味着你向运维承诺：“我最多积压320个