为何此场景下新线程池的嵌套并行流比commonPool快20倍？

核心原因 #

你的测试结果差异本质是ForkJoinPool.commonPool()的线程资源竞争导致任务阻塞/饥饿，而独立线程池通过资源隔离避免了这个问题，充分利用了CPU核心。

详细拆解 #

1. CommonPool的线程数限制与嵌套阻塞 #

默认情况下，ForkJoinPool.commonPool()的线程数为可用CPU数-1——你的环境是12核，所以CommonPool只有11个工作线程。

当外层并行流启动32个任务时，这些任务会占满CommonPool的所有线程。每个外层任务又会启动内层并行流，而内层流默认也使用CommonPool。此时CommonPool已经没有空闲线程，内层任务只能排队等待外层线程释放，形成外层任务等待内层任务、内层任务等待空闲线程的恶性循环，导致整体执行效率极低。

直白来说：外层把CommonPool的线程全占了，内层并行流根本拿不到线程干活，只能串行等待，相当于每个外层任务都在串行执行内层的32个sleep操作，耗时被大幅拉长。

2. 独立线程池的资源隔离优势 #

testingNewPool中，每个外层任务都创建一个独立的ForkJoinPool（默认线程数等于可用CPU数，即12）。这样内层并行流的任务不会和外层任务抢CommonPool的线程资源：

• 外层并行流用CommonPool的11个线程同时执行任务
• 每个外层任务的内层并行流，都能在自己的独立线程池中并行处理32个sleep任务，充分利用CPU核心，没有阻塞等待

这种资源隔离让内层任务的并行能力完全释放，整体执行时间被大幅压缩，所以吞吐量比CommonPool嵌套场景快了一个数量级。

3. 串行内层流的表现对比 #

testingCommonPoolWithSequentialInner的吞吐量比CommonPool嵌套并行还低，原因很直接：内层是串行执行32个sleep操作，每个外层任务的耗时就是32*5ms=160ms，而嵌套并行场景下，内层还能通过ForkJoin的工作窃取机制偶尔拿到少量线程，所以比纯串行内层快一点，但依然远不如独立线程池。

对应测试数据的验证 #

• testingNewPool（22.6 ops/s）：外层32个任务用11线程并行，每个任务的内层用12线程并行处理32个sleep，内层耗时约15ms（32个任务分3批执行，每批5ms），外层32个任务分3批执行总耗时约45ms，每秒可完成约22次完整测试，和你的结果匹配。
• testingCommonPool（1.9 ops/s）：外层11线程占满CommonPool，内层只能串行执行，每个外层任务耗时160ms，32个任务分3批执行总耗时约480ms，每秒仅能完成约2次，和测试结果一致。

总结 #

嵌套并行流场景下，共享CommonPool会导致线程资源被外层任务耗尽，内层并行流无法发挥作用，引发严重的性能瓶颈。为内层任务分配独立的ForkJoinPool，通过资源隔离避免了线程竞争，让CPU资源得到充分利用，这就是性能差异的核心原因。

内容的提问来源于stack exchange，提问作者Andorrax