CPU密集型任务线程池调优：从公式到压测的量化实践

1. 从现象说起：为什么"调线程池大小"不能靠经验和猜

接手任何一个多线程业务，第一关永远绕不开线程池参数配置。很多团队一上来就复制一套"标准参数"，corePoolSize=8、maxPoolSize=16、queueCapacity=1000，看起来天经地义，实际一压测就出问题。

这个问题的根子在于：密集计算任务的线程模型和普通业务请求处理模型是完全不同的，不能共用同一套调优套路。

所谓"密集计算"，指的是任务的运行时间主要消耗在CPU计算、内存读写、数据聚合这类本地计算上，而不是在等待数据库、外部HTTP接口、消息队列这些远端资源返回。两者的本质区别在于：IO密集任务里线程大部分时间在"阻塞等待"，线程数可以开得很大；而密集计算任务里线程大部分时间在"拼命跑"，线程数开多了反而互相争抢CPU时间片，上下文切换的开销比计算本身更贵。

举个例子。某个数据处理系统，每秒钟要处理几万条日志，每条日志需要做正则提取、字段规整、内存累积排序，单条耗时大约1.5毫秒。最初团队按照"一个请求一个线程"的思路，把线程池开到200，以为处理得更快，结果CPU直接冲到95%以上，但吞吐量反而比线程数=CPU核心数时还低。问题就出在：200个线程在同一批物理核上反复切换，光保存和恢复线程上下文就吃掉大量CPU周期。

这篇文章会告诉你：如何准确判断你的业务属于什么类型的任务，怎么用一套"可计算、可验证"的方法去确定线程数、队列长度和拒绝策略，以及在线程池之外，架构层面上还有哪些隔舱、熔断和分片手段能压榨密集型任务的最大吞吐。全程不靠直觉，全部用参数计算和压测数据说话。

不管你是写实时计算中间件的开发者、维护后台批处理系统的主力工程师，还是刚接触并发编程不久想弄明白"为什么线程池调大反而变慢"的新人，这篇文章都值得读完。

顺便强调一点：接下来讲的调优思路不仅适用于Java技术栈。只要你的语言运行时里有线程、协程或者Actor模型，这套"先建模、再计算、后压测验证"的方法论都通用。

2. 任务建模先行：搞不清类型，调优无从谈起

2.1 CPU密集型、IO密集型与混合型的判定方法

进入参数调优之前，先花五分钟做任务画像。你要回答三个问题：单个任务里，纯计算时间占比是多少？有没有同步等待？等待的粒度是什么？

• CPU密集型：任务基本不阻塞，跑满一个线程的所有时间片。典型场景：图像滤镜计算、金融风控评分模型推理、批量编解码、数据压缩。判断依据：任务方法堆栈里几乎看不到wait/sleep/epoll之类的调用，线程状态绝大部分时长为RUNNABLE。
• IO密集型：任务大量时间在等待网络响应或磁盘IO。典型场景：HTTP接口调用、数据库读写、文件搬运。
• 混合型：先查缓存、再计算、再写结果，每一段都有阻塞也有计算。绝大多数业务代码属于这一类。

如何量化和判断？有一个简单办法：在测试环境用单线程跑一遍真实任务，分别统计CPU占用时间和阻塞等待时间。如果你的采样工具不方便，可以粗略采用经验比例：

如果等待时间长、计算时间短，IO占比高，线程数可以开大。如果两个时间差不多，按混合型处理。如果计算时间远大于等待时间，你是典型的CPU密集型，人云亦云的"线程数=CPU核心数+1"才能发挥作用。

很多开发者容易忽略一点：同样一段代码，在不同硬件环境下，类型可能发生变化。例如本地缓存命中率很高时，某服务是CPU密集型；一旦缓存命中率下降，大量请求穿透到数据库，它就变成了IO密集型。所以任务建模不是一次性工作，每轮架构重构后都应该重新评估。

2.2 性能指标基线：吞吐量、延迟与资源利用率的三角考量

调线程池本质上是沙雕游戏——在吞吐量（每秒处理任务数）、延迟（单个任务完成时间）、资源利用率（CPU/内存）三个指标之间找平衡点。不可能三角里，极端追求吞吐往往会牺牲延迟抖动。

我建议在建模阶段就把这三个指标明确的量化目标写出来。比如：

没有目标就去调线程池，等于拿着方向盘不知道目的地，最后只能靠"看起来不高"和"感觉还行"来验收，这是很多线上事故的源头。

另外要建一套压测基准。压测工具推荐直接用JMH做单任务耗时的微基准，然后用wrk或者自研压测脚本测整体吞吐。只有把单点耗时和全局吞吐分开测量，你才知道自己的优化到底起效在哪个环节。某些时候单任务耗时没变，但吞吐翻倍了，说明线程池调度效率提升了；反过来单任务耗时恶化但吞吐没变，说明线程分配策略给任务执行本身拖了后腿。

3. 线程池参数调优：不再背公式，而是"算账"

3.1 核心参数的关系：corePoolSize、maximumPoolSize、queueCapacity和拒绝策略

线程池的设计比大多数人以为的复杂，它像一个讲究流程的工厂车间：

• corePoolSize：车间里常驻的工人数量。不忙的时候也要养着。
• maximumPoolSize：急单下来，车间最多可以临时招到多少工人。
• queueCapacity：车间门口的待处理工单架，能堆多少活儿。
• 拒绝策略：工单架也满了、工人都满了，新单子怎么处置。

一个重要事实是：任务提交顺序不是"先启动corePoolSize线程，满了直接扩容到maximumPoolSize"，而是线程数达到corePoolSize后，新的任务先进队列排队；队列填满之后，才会继续创建线程直至maximumPoolSize；线程数到maximumPoolSize且队列也满了，才触发拒绝策略。

这个顺序对密集计算任务至关重要。如果队列开得很大，线程数永远涨不到maximumPoolSize，你配置的扩容参数形同虚设。反过来，如果把队列开得极小甚至用SynchronousQueue，那又等于完全不做缓冲，一有任务就尝试创建新线程，极端情况下线程频繁创建销毁非常伤性能。

密集计算场景下，我推荐直接使用有界队列，最常用的是ArrayBlockingQueue。队列长度不要拍脑袋，下文给出计算方法。

3.2 密集计算场景的核心线程数计算方法：Ncpu + 1 背后的真相与分析

网上流传最广的经验公式是：

• CPU密集型：线程数 = CPU核数 + 1
• IO密集型：线程数 = CPU核数 × (1 + 平均等待时间 / 平均计算时间)

先说"CPU核数 + 1"这条公式。它源自经典操作系统的线程调度实验：当线程数等于核心数时，线程恰好占满每个核心，但偶尔一个线程因为缺页中断、锁竞争或者GC停顿而短暂让出CPU，就少了一个核心在干活。多出来的1个线程，正好填补这类短暂空档，让CPU保持着满载状态。它是"用1个线程的微小上下文切换开销换取CPU空转概率大幅下降"的划算买卖。

但这只是理论值。现代服务器CPU通常开启了超线程，一个物理核呈现为2个逻辑核，Runtime.getRuntime().availableProcessors()拿到的是逻辑核数量。对于纯计算密集任务，超线程带来的吞吐提升大约只有15%到30%，并非翻倍。直接拿逻辑核数去算线程数，不一定最优。我建议自主机器的场景直接按物理核数量，容器环境则要认真考究一下。

3.3 容器环境下的CPU核数获取与参数动态化配置

容器场景是个深坑。在Kubernetes或者Docker里，Java进程如果不配合容器参数，availableProcessors()可能返回的是宿主机总核数而不是容器配额内的核数。比如宿主机64核，容器限制4核，Java仍然认为自己是64核机器，线程池按64核去计算，直接超卖。

从JDK 8u191开始，JVM默认启用容器感知的CPU资源限制，availableProcessors()能正确返回容器配额。如果你还停留在旧版本，必须显式加上JVM参数：

java -XX:ActiveProcessorCount=4 -jar application.jar

如果你的服务是按Pod维度独立部署，每个Pod独占一个实例，那么核心线程数可以基于容器配额进行计算。如果多个Pod混部在同一批物理机上，还需要把物理机层面的竞争考虑进去，我团队的做法是预留至少20%的CPU余量，不把线程数按满额计算，防止宿主上其他容器的毛刺拖垮自己。

动态配置也很重要。不建议把这些参数写死在代码里，最好用配置中心下发：

@Configuration @ConfigurationProperties(prefix = "task.executor") public class ThreadPoolProperties { private int corePoolSize; private int maxPoolSize; private int queueCapacity; private String threadNamePrefix = "calc-task-"; // 标准的getter/setter略 }

3.4 队列容量和拒绝策略的确定：延迟还是丢弃，要用数据说话

队列容量在密集计算中决定的是"背压"机制。队列越长，任务堆积容忍度越高，但代价是任务等待时间拉长，而且一旦系统崩溃，内存里积压的任务全部丢失。队列太短，等于拒绝策略频繁触发，直接丢弃业务请求，导致任务成功率下降。

正确做法是结合预期的峰值流量和可接受的排队延迟来算。假设任务平均耗时T（毫秒），队列里最多容忍的任务等待时间为W（毫秒），那么合理容量约等于W / T。比如单条任务平均耗时100ms，你允许任务在队列里最多等5秒，那么队列容量500左右。超过500的时候就要思考：是继续排队等，还是丢一部分任务保护系统稳定，或者让上游限流。

在拒绝策略上，Java内置了四种策略，但密集计算任务推不推荐使用CallerRunsPolicy的呼声比较两极分化。CallerRunsPolicy的执行逻辑是如果线程池满，任务就回退到调用方线程执行。对IO密集场景它天然像一个反向限流阀：调用方线程被占住，自己就不发新请求了。但密集计算场景里，调用线程往往是接收请求的核心线程，如果它被回退任务拖住，后续请求没人接收，很可能是灾难。所以我的建议是：密集计算场景，如果任务允许丢弃，用DiscardPolicy并配套监控；如果不允许丢弃，宁可自定义BlockingPolicy，用生产者线程阻塞等待，也不要让调用线程去执行任务。

自定义阻塞式拒绝策略代码片段如下：

public class BlockWhenQueueFullPolicy implements RejectedExecutionHandler { @Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { try { executor.getQueue().put(r); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RejectedExecutionException("任务提交中断", e); } } }

阻塞队列的put会让提交线程阻塞直到队列有空位，相当于手动把背压传导给上游。期间配合信号量控制最大排队任务数，防止内存无限增长。

4. 真正的量化调优流程：压测、监控与二次校准

4.1 从理论公式到初步参数：一个具体案例的计算拆解

我拿最近做的一个模拟计算服务来举例。硬件环境：一台物理机，8核16线程，业务是风控特征计算，每个任务平均计算耗时80ms，任务之间无依赖，允许部分丢弃，要求P99延迟不超过2秒。

按CPU密集型初步计算：

• 物理核数8，理论核心线程数=8+1=9。
• 预留20% CPU余量，保守设置为7。
• 队列容忍等待时间 = 目标P99（2000ms） - 任务耗时（80ms） ≈ 1920ms。
• 队列容量 = 1920 / 80 ≈ 24。

于是初始参数：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 7, // corePoolSize 12, // maximumPoolSize 30L, TimeUnit.SECONDS, // 非核心线程空闲回收时间 new ArrayBlockingQueue<>(24), new NamedThreadFactory("feature-calc"), new ThreadPoolExecutor.DiscardPolicy() );

maximumPoolSize为什么是12？理论上最大线程数应该是"排队也堵不住时的最大工人数"，考虑到短时流量尖峰，允许比核心线程多出约50%~70%的容量。这里7->12就是结合历史上峰值流量的经验值，而非公式值。

4.2 压测工具的选择与执行：JMH测准单点，wrk测准整体

单点耗时基准用JMH写一个简单的微基准：

@State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MILLISECONDS) public class FeatureCalcBenchmark { @Benchmark public void testCompute() { // 构造一个真实特征计算任务 FeatureCalculator.calculate(sampleFeature); } }

注意，JMH的默认fork和warmup配置一定要保留，否则JIT编译导致的结果偏差会误导你。多试几次，取平均值和方差。

整体吞吐和延迟压测，我更推荐直接用自研的多线程压测客户端，模拟生产环境的提交模式。比如用50个线程以每秒固定速率提交任务到被测服务，统计P50、P90、P99延迟和吞吐量。wrk对HTTP服务顺手，但这个场景的压测重点在于任务提交模式的真实性。

4.3 监控指标怎么定：队列深度、活跃线程数、拒绝次数才是核心

调优之后，最怕的是"以为改了参数就完事"。上线前，必须把JMX暴露的线程池指标接入已有监控系统：

• activeCount：活跃线程数，如果长期等于corePoolSize，说明核心线程已经满载，要看队列增长趋势。
• queue.size()：队列深度，如果持续增长，说明消费速度跟不上生产速度。
• completedTaskCount：完成任务总数。两次采样差值除以间隔时间，就是真实吞吐量。
• rejectedCount：拒绝任务数，这个只要有增长就必须告警，说明系统已经过载。

我把它们打包成一个线程池包装器，定期将指标推到监控系统。

实际踩过的坑是：刚开始只监控了吞吐量，没有监控队列深度，结果队列积压到3万条内存暴涨，服务OOM。密集计算任务的数据对象往往比较大，队列里积压的每条任务都占内存，计算时务必把"队列任务的内存占用"纳入容量规划。

4.4 二次校准：参数不是一次定死，而是跟随流量波动的活值

压测数据往往只能反映编写压测脚本当时的状态。线上流量是波动的，比如早晨高峰和凌晨低谷的提交速率可能差10倍以上。我建议做两件事：

第一，给核心线程数设置一个合理的空闲回收时间，让线程池在低峰期自动释放部分线程。核心线程默认不会被回收，看业务情况决定是否允许allowCoreThreadTimeOut(true)。

第二，高峰低谷切换时，动态调整corePoolSize和queueCapacity。现在Java的ThreadPoolExecutor提供了setCorePoolSize()方法，可以在运行时调整。不过要注意：调低corePoolSize并不会立刻中断正在跑的线程，只会影响后续的线程回收节奏，所以调整要提前，不要等线程数已经膨胀才想起缩小。

5. 进阶武器：虚拟线程与ForkJoin在密集计算中的适用边界

5.1 虚拟线程能解决密集计算问题吗？一个容易踩的认知误区

JDK 21虚拟线程出来以后，很多团队欢呼雀跃：线程数终于可以随便开了！但这里有一个必须说清楚的认知误区：

虚拟线程的优势在于大幅降低阻塞型任务的调度开销，它解决的是"IO密集型任务中线程阻塞浪费资源"的问题，而不是"CPU密集型任务中核心算力不够"的问题。

把100万个虚拟线程扔给密集计算任务，每个虚拟线程在CPU上执行时仍然要和其他虚拟线程轮流占用物理核心，一旦任务不吃IO、纯粹跑计算，虚拟线程和物理线程调度的底层开销差异就消失了。更麻烦的是，虚拟线程栈在JDBC这类同步IO场景会触发固定，但在纯计算场景并不会带来吞吐提升，反而因为线程数量太大，任务上下文和迁移的开销在某些实现里是个负担。

我的建议：如果你的任务类型是"计算但内部有同步等待"，比如混合型任务，虚拟线程值得尝试。如果是纯CPU计算，老老实实按上一节的模型配平台线程池，不要为了新技术而新。这里不是不推荐使用，而是用之前先做一次小范围压测对比，拿数据下结论。

5.2 ForkJoinPool在工作窃取场景中的正确用法

ForkJoinPool适合的是"一个大任务可以被拆成无数个小任务，小任务结果可以合并"的递归分治计算。典型的例子：大数组排序、矩阵乘法、树结构遍历。

密集计算场景里，如果任务颗粒度足够细，ForkJoin默认的工作窃取机制会让空闲线程主动去偷其他线程队列里的任务，让CPU核心尽量不闲着。但要注意：ForkJoinPool的并行度参数，默认等于availableProcessors()，这个数和平台线程池的核心线程数会叠加竞争。

我在框架层常用的策略是：把全局线程池和ForkJoinPool托管的线程总数控制在CPU核心数附近。要么计算任务统一走自定义线程池，要么统一走ForkJoinPool，不要双层并行，否则两者抢CPU资源可能互相拖垮，定位问题时还很难查是哪个池的问题。

5.3 轻量级限流组件：信号量与令牌桶在提交端的配合

线程池本身的队列是背压点，但只在队列满时才触发。更好的做法是在提交端就加上限流，让线程池始终工作在安全水位上。我提到的信号量限流方案很成熟：

public class TaskSubmitGate { private final Semaphore gate; public TaskSubmitGate(int permits) { this.gate = new Semaphore(permits); } public boolean trySubmit(Runnable task, ThreadPoolExecutor executor, long timeout, TimeUnit unit) { boolean acquired = false; try { acquired = gate.tryAcquire(timeout, unit); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } if (!acquired) { return false; // 或者在这里记录限流日志 } try { executor.execute(() -> { try { task.run(); } finally { gate.release(); } }); return true; } catch (RejectedExecutionException e) { gate.release(); return false; } } }

信号量许可数就相当于"线程池正在处理的+队列里等待的"任务总数上限。这样即使线程池参数没调到完美，提交端已经上了一道保护层。专业的架构里，限流一定要放在最前面，线程池只是第二道防线。

6. 架构设计层面的密集计算优化：从单机到分布式的思路演进

6.1 任务分片与合并：用最小分片粒度控制CPU利用率

单机内部优化有天花板，要进一步提高密集计算的吞吐，就要在任务进门之前把任务拆好。

数据分片的核心是"每片任务大小要均匀"。如果一份任务分成8份，其中7份每份1秒，最后一份10秒，最终完成时间被最慢的拖到10秒，其他线程全部空等。均匀切分的计算粒度，在密集计算场景里直接决定了CPU利用率上限。

我自己用得最多的是"总量已知时按记录数均分，总量未知时按分片耗时反馈动态调整"的组合，实测下来比固定分片提升了近40%的CPU利用率。

6.2 本地缓冲 + 批量提交：减少任务排队次数，提高吞吐密度

方案设计上，把"任务"的颗粒度放大，不要在业务层一次只提交一条记录。举例：一个数据清洗任务，如果一行一行提交，每次都要走一次任务封装和队列交互，开销占比可能超过10%。把1000行封装成一个批次任务，线程池的压力瞬间降低1000倍，而且批量计算能更好地利用CPU缓存局部性。

实现方式可以是在生产者侧做一个缓冲队列，积累到指定条数后一次性提交：

public class BatchAccumulator { private final List<Record> buffer = new ArrayList<>(); private final int batchSize; public synchronized void add(Record record) { buffer.add(record); if (buffer.size() >= batchSize) { flush(); } } private void flush() { List<Record> batch = new ArrayList<>(buffer); buffer.clear(); executor.execute(() -> batchProcessor.process(batch)); } }

这里的批量大小不是越大越好。批量太大会导致批次内处理时间过长，P99延迟飙升。我一般以单批次执行时间不超过500ms为标准来倒推批量大小。

6.3 分布式扩展：分区队列与结果聚合的模式选择

当单机怎么调都到不了目标吞吐量时，就要上多节点。分布式密集计算的本质是"把任务分到多台机器，把结果收回来"。

最常见的模式是生产者-消费者模式变的：生产者把任务写入消息队列，多个消费者进程并行消费。注意，这里消息队列就是线程池之外的第二层背压，相比本地内存队列，它能承受的堆积量大得多。队列分区数最好等于消费者实例数，这样每个消费者独占一个分区，避免多个消费者抢同一分区的锁竞争。

还有一种模式是直接使用并行流式的框架，核心思想是把任务集分割成多个子任务下发到不同节点并行执行，再收集子结果合并。适合计算密集且可并行化的统计类、聚合类任务。但如果任务之间有依赖，比如"下一步需要上一步的结果"，就不适合盲目并行，需要先做依赖拓扑分析。

6.4 熔断、隔离与降级：过载时保住核心吞吐

前面都在讲如何提高吞吐，但架构上还有一个重要议题：过载时怎么办。密集计算服务最容易出现的问题是：流量突然翻倍，线程池瞬间打满，队列堆积，然后GC压力暴增，最后OOM。整个服务挂掉，不如直接丢弃一部分不重要的任务。

我的实践经验是三层保护：

• 第一层：提交端限流。拒绝率超过阈值时，直接在上游丢弃低优先级任务。
• 第二层：线程池隔离。不同优先级或不同类型的计算任务，用不同线程池，不要混用。比如"实时评分任务"和"离线批量报表任务"就应该隔离。一个批处理高峰把实时业务卡死，是架构设计的耻辱。
• 第三层：熔断降级。当线程池的拒绝率连续超过5%，主动熔断非核心功能，保证核心P99指标不崩溃。

下面是一个基础的熔断记录器：

public class CircuitBreaker { private final AtomicLong recentRejections = new AtomicLong(); private volatile boolean open; public void recordRejection() { long count = recentRejections.incrementAndGet(); if (count > 100 && !open) { open = true; // 触发降级逻辑，例如拒绝离线报表任务 } } public void reset() { recentRejections.set(0); open = false; } }

7. 常见问题与排查技巧实录

7.1 线程池"看起来没满"，任务却迟迟不执行

排查思路：先看任务提交到了哪个队列，如果队列积压，说明消费速度不够。可能是某个任务里不小心加了同步锁，导致线程全部在等锁。最典型的场景是任务内部调用了某个全局单例的synchronized方法，虽然是密集计算，却发生了隐性的IO等待（锁竞争）。

解决办法是：在线程池任务执行前后打印线程状态快照，用jstack看看大量线程是RUNNABLE还是BLOCKED。如果是BLOCKED，直接找锁。

7.2 调大线程池后吞吐量不升反降的经典原因

CPU密集型任务调大线程数到超过物理核数量，上下文切换开销占比上升，吞吐量反而下降。用top -H查看各个线程的CPU占用率，如果大量线程处于R状态但单线程CPU时间片被切得很碎，基本就是这个原因。

另一个隐藏因素是JVM的GC线程。并行垃圾回收器线程数默认随CPU核数增长，如果线程池把CPU全部占满，GC线程启动会让所有计算线程一起STW，延迟抖动非常严重。这种情况下，可以考虑调整GC线程数，或者在线程池设计时故意留出一部分CPU余量。

7.3 任务结果丢失或重复计算的补偿处理

使用DiscardPolicy时，任务被丢弃后是静默消失的。生产环境必须确保丢弃的任务有重试或者补偿机制。最简单的补偿方案：被拒绝的任务记录到本地失败表中，额外一个定时任务扫描重试。

如果任务是可重入的，用DiscardPolicy加失败记录表；如果任务不可重入，就别用丢弃策略了，改用BlockWhenQueueFullPolicy，牺牲一点上游速度换取不丢数据。这块取舍在系统设计的时候就要想清楚，不能在流量高峰时才来纠结。

7.4 小而快与大而重的任务混跑，如何隔离

一句话：不要混跑。CPU密集场景下，一个小任务占5ms，一个大任务占5秒，如果同一个线程池，小任务会被大任务堵在后面，P99会被拉得极难看。

标准做法是拆分为两个线程池：

• fastPool：核心线程数=CPU核心数×80%，队列很小，用于短计算任务。
• slowPool：核心线程数=CPU核心数×20%，队列较大，用于长计算任务。

两套池的资源总和不要超过物理核数，否则仍是竞争加互相干扰。

7.5 排查手段速查表

8. 几个很容易被忽略的底层支撑点

8.1 任务对象的创建与GC开销

密集计算场景里，每创建一个任务Runnable对象，就是一份内存垃圾。如果每秒提交几万个任务，瞬时对象产生量非常可观，Young GC频率会被拉高。

优化方向有两个。第一，尽量复用任务封装对象，比如批量任务代替单条任务，显著减少对象数量。第二，如果你们用JDK 17+，可以尝试用record类定义轻量任务对象，减少运行时开销。另外注意代码里不要在任务执行过程中大量创建中间数组，尽量复用工作数组。

8.2 线程工厂定制：给每条线程一个可识别的名字和优先级

出线上问题时，jstack里如果全是pool-3-thread-1，整个排查过程会很痛苦。从第一天起就用自定义线程工厂：

public class BusinessThreadFactory implements ThreadFactory { private final String prefix; private final AtomicInteger counter = new AtomicInteger(0); public BusinessThreadFactory(String prefix) { this.prefix = prefix; } @Override public Thread newThread(Runnable r) { Thread t = new Thread(r, prefix + "-" + counter.incrementAndGet()); t.setDaemon(false); t.setUncaughtExceptionHandler((thread, throwable) -> log.error("Unhandled exception in thread {}", thread.getName(), throwable)); return t; } }

给线程取名这种小事，排查故障时能省下一两个小时，非常划算。任何生产环境的线程池，都不应该看到默认的pool-x-thread-y命名。

8.3 JVM参数层面的配合：不要忽视新生代大小与CPU核数匹配

密集计算任务在运行时会大量产生临时对象，新生代太小会导致频繁Minor GC，线程被频繁暂停。实践中的经验是：并行度越高，新生代应该越大。因为线程数多，同时产生的垃圾量也大，新生代太小会让GC成为全局瓶颈。

一个比较保守的启动参数参考：

java -Xms4g -Xmx4g -Xmn2g -XX:SurvivorRatio=8 -XX:+UseG1GC -jar application.jar

G1的Region动态调整机制在密集计算场景下表现比较稳。如果你还在用CMS，建议借这个机会迁移到G1，线上的长尾延迟能改善不少。

9. 最后再分享一点我这些年的切身体会

调线程池这件事，踩过的坑越多，越能明白一个道理：不要试图用一套"万能参数"应对所有场景。

每次调优之前，先花30分钟画一张流程图，弄清楚任务到底从哪来、要经过哪些处理、最终去哪，这30分钟能省下后面3天的排查时间。画图的过程就是任务建模的过程。什么情况下用大线程池、什么情况下用小线程池、什么情况下要上消息队列做缓冲，画完图基本就有答案了。

另外一个心得是，团队里一定要有一个人专门负责线程池参数的维护和文档记录，否则过了三个月，没人知道当初为什么配成9、为什么队列长度是24，也就没法做后续优化。我见过太多团队，参数被改来改去，线上出了问题就随便调大一个值，结果越调越糟。把每次调整的原因和压测数据固化下来，这比参数本身更重要。

如果你要做一次彻底的密集计算优化，可以按照"任务建模 → 参数初算 → 单点压测 → 整体压测 → 调整参数 → 监控复盘"这个顺序走一遍，每一步都用真实数据说话。等你经历过一次从CPU跑不满到吞吐翻倍的优化过程，你对并发的理解会上一个台阶，这套方法论也能复用到团队里的其他服务上。