ForkJoinPool 这个名字听上去好像很底层但只要用过 Java 并行流或者写过分治算法你八成已经和它打过交道。很多同学把 parallelStream 当成魔法一样用任务一丢就完事遇到性能忽高忽低、线程卡死或者 CPU 跑不满就完全没了头绪。问题往往就出在没搞懂背后的 ForkJoinPool。这篇文章不打算做源码逐行注释更想从“设计者为什么要这么做”的角度把分治思想和工作窃取算法这两件事拆开揉碎讲清楚。我会用实际能跑的代码、调参的经验、以及我踩过的几个坑帮你在日常项目里真正把 ForkJoinPool 用明白。1. ForkJoinPool 到底是什么它在并发库里处在什么位置1.1 传统线程池在“大任务拆小任务”场景下的短板Java 并发这块大家用得最多的就是 ThreadPoolExecutor。它的模型是你提交一批独立任务线程池用固定数量的线程去消费一个共享队列。每个任务之间相互独立、互不等待这种场景下 ThreadPoolExecutor 表现非常好。但如果你面对的是一个可以递归拆分的计算任务比如“算 0 到 100 万的和”天然思路是切成两半、四半、八半让不同线程分别算最后汇总。用 ThreadPoolExecutor 怎么做你把每个子任务都 submit 到池里然后主线程 future.get() 等待结果。子任务又会继续拆分子子任务再次 submit。任务越拆越多线程池的队列被反复塞入微小任务线程切来切去尤其是父任务要等子任务返回会大量占用线程资源白白等待。线程池里一个线程可能在 get() 上阻塞导致活跃线程数量虚高真正干活儿的反而没几个。这就是 ForkJoinPool 出现的核心原因它要支持的不是“一批独立任务”而是“一个可以递归分裂且互相之间有依赖关系”的任务树。1.2 一个池子、两类灵魂分治 窃取ForkJoinPool 之所以能在 JDK 7 加入、并在 JDK 8 成为并行流底层是因为它同时解决了两件事。第一件事是拆分任务通过 fork() 把子任务异步甩出去通过 join() 等待子任务结果。这对应着“分治思想”里的分和合。第二件事是负载均衡一个任务被拆开后可能某些子任务特别快某些特别慢。如果每个线程各守一个队列很快就会出现有人忙死、有人闲死。工作窃取算法让空闲线程去“偷”别人的任务来做从而让 CPU 尽可能被占满。ForkJoinPool 本质上就是一个特殊的线程池它维护的 worker 线程数量默认和 CPU 核数相关每个 worker 维护自己的双端任务队列。这个设计听着简单但里面的门道不少我后面详细展开。2. 分治思想先学会把任务拆到“不用再拆”2.1 怎么用递归来定义一个大任务分治的核心是把一个规模为 N 的问题拆成若干个规模更小的同类问题递归下去直到规模小到可以直接求解然后逐层合并。以归并排序举例对数组 [5, 2, 9, 1, 7, 6] 排序可以拆成左半边 [5, 2, 9] 和右半边 [1, 7, 6]各自排序后再合并。ForkJoinPool 里这种任务被封装成 ForkJoinTask。你通常不直接继承 ForkJoinTask而是继承它的两个现成子类RecursiveAction任务没有返回值典型场景是数组排序、遍历改写。RecursiveTask任务有返回值典型场景是和、最大值、统计类计算。这两个类都只有一个必须实现的抽象方法 compute()。你在 compute() 里判断当前任务够不够小够小就直接算不够小就继续拆。2.2 阈值拆到哪一层才停分治最关键的“度”就是阈值THRESHOLD。阈值太大会导致单个任务依然很大多线程没充分用起来退化成串行阈值太小会导致子任务数量爆炸线程间的协调开销超过了计算本身的收益。举个例子对一个包含 1000 万元素的数组求和直接 fork 到单元素级别会产生约 2000 万个任务对象任务调度压力巨大结果大概率比单线程 for 循环还慢。阈值怎么选经验和基准测试缺一不可。我一般先按“每个任务至少干 10000 到 100000 次简单操作”为标准来初选然后用不同阈值对照跑几遍挑出耗时最低的。具体数值没有通解和 CPU 缓存、内存带宽、任务本身的复杂度都有关。记住一个原则任务拆分和合并的开销必须远小于任务本身的计算量。3. 工作窃取算法一个巧妙到让人拍大腿的负载均衡机制3.1 双端队列任务不是排队而是“抢活”ForkJoinPool 和 ThreadPoolExecutor 在队列设计上有个根本区别。ThreadPoolExecutor 是多个线程共享一个阻塞队列ForkJoinPool 是每个工作线程worker拥有自己的双端队列deque。当线程 A 执行任务 T1T1 通过 fork() 拆出子任务 T1.1、T1.2 时这两个子任务不会丢到一个全局队列而是直接塞到线程 A 自己的队列头部。线程 A 继续往下执行遇到 join() 时会从自己的队列头部取出任务来处理。注意这里用的是 LIFO后进先出也就是说最新拆出来的子任务会被优先执行。为什么因为刚拆出来的子任务的数据大概率还在 CPU 缓存里现取现用缓存命中率最高。其他线程呢它们如果自己的队列空了就去别的线程的队列尾部“偷”任务。这个操作是从尾部取和生产端头部、消费端头部都不冲突只需要在偷取时加一点点同步即可。这种设计叫双端队列结合工作窃取。3.2 为什么窃取能提升整体吞吐量没有工作窃取的话如果任务拆分得不均匀某个线程的队列里堆了一堆任务另一个线程却空转CPU 利用率就上不去。工作窃取让“闲人”主动跑到“忙人”那里分担任务。窃取的粒度是整个任务块而不是单条 CPU 指令因此摊薄下来的同步开销极低。我用一个生活化的类比食堂打饭窗口。如果每个窗口前都固定排一队人某个窗口的厨师动作慢队伍越排越长而旁边的窗口已经没人了厨师在聊天。工作窃取就是允许这个闲着的厨师直接从旁边窗口的队尾拉几个人过来打饭。这不仅让做饭快的窗口能多干活也让闲着的人不至于白拿工资。4. 核心类与参数难点别等报错了才回头学4.1 ForkJoinTask 的三种操作模式ForkJoinTask 最核心的方法就三个fork()异步执行当前任务。注意在 ForkJoinPool 里fork() 并不等于新开一个操作系统线程而是把当前任务放入当前 worker 的队列由同一个 worker 或其他空闲 worker 后续执行。这是一种轻量级调度。join()等待任务返回结果。如果当前线程就是执行该任务的线程它会直接从队列里取任务继续干活而不是傻等。这个设计叫“任务内联执行”。invoke()在当前线程里同步执行任务等价于 fork join 的简化写法。有个初学者很容易搞错的点join() 不是阻塞等待它是一种紧密耦合的协作机制。如果 A 任务 join 了 B 任务而 B 还没开始跑A 所在的 worker 不会干等着而是会去执行其他任务直到 B 的结果就绪。这个机制保证了线程不会因为依赖关系而闲置。4.2 parallelism 和 commonPool到底该怎么设ForkJoinPool 的构造参数中最核心的是 parallelism。它决定池里工作线程的数量。如果不填默认值是 CPU 核心数减一。这个“减一”是因为 main 线程本身也会参与任务执行所以池里不需要留一个专门的线程去配合它。parallelism 不是越大越好。如果你的任务是 CPU 密集型设成核数或核数减一是最稳的。设多了线程切换开销反而拖慢速度。如果任务里包含 IO 或阻塞操作那 ForkJoinPool 并不适合你应该另起专门的线程池。另外JDK 8 之后所有并行流默认使用 ForkJoinPool.commonPool()它是 JVM 级别共享的池。如果你在同一个 JVM 里到处用并行流又提交了重量级自定义任务大家会一起抢这些线程很容易互相拖垮。这也是很多“并行流性能诡异”问题的根源。5. 从入门到实战一个可落地的数组求和案例5.1 最基础的 RecursiveTask 实现我先写一个最经典的求和案例你可以直接拿去跑import java.util.concurrent.RecursiveTask; import java.util.concurrent.ForkJoinPool; public class SumTask extends RecursiveTaskLong { private static final int THRESHOLD 10_000; private final long[] array; private final int start; private final int end; public SumTask(long[] array, int start, int end) { this.array array; this.start start; this.end end; } Override protected Long compute() { int length end - start; if (length THRESHOLD) { long sum 0; for (int i start; i end; i) { sum array[i]; } return sum; } int mid start (end - start) / 2; SumTask leftTask new SumTask(array, start, mid); SumTask rightTask new SumTask(array, mid, end); leftTask.fork(); long rightResult rightTask.compute(); long leftResult leftTask.join(); return leftResult rightResult; } public static void main(String[] args) { long[] input new long[10_000_000]; for (int i 0; i input.length; i) { input[i] i 1; } ForkJoinPool pool new ForkJoinPool( Runtime.getRuntime().availableProcessors() - 1 ); long startTime System.currentTimeMillis(); Long result pool.invoke(new SumTask(input, 0, input.length)); long endTime System.currentTimeMillis(); System.out.println(结果: result , 耗时: (endTime - startTime) ms); pool.shutdown(); } }注意我在 compute() 里的拆分技巧leftTask.fork() 将左半部分异步丢出去右半部分直接在当前线程里 compute()然后再 join 左半部分。这么做比“两边同时 fork 再同时 join”更高效因为当前线程避免了一次不必要的队列调度直接参与了右半边的计算。5.2 阈值调优的实操笔记我分别用 1000、10000、100000 三个阈值跑过这个程序在 8 核 CPU 上结果大致是阈值拆分任务数约耗时ms100020000 个左右大幅增加任务管理开销明显100002000 个左右最优区间100000200 个左右接近串行线程未充分利用阈值过低时ForkJoinPool 会频繁执行 fork 和 join大量短命任务在队列里进进出出得不偿失。阈值过高拆分不到足够的子任务多核优势发挥不出来。所以调优方向永远只有一个在实际数据规模和真实 CPU 环境下做基准测试别拍脑袋设值。5.3 一个小技巧用 invokeAll 简化 fork 双分支上面的代码为了展示 fork/join 的整个过程我手动处理了两边。日常开发中两个子任务同时拆的场景可以直接用 ForkJoinTask.invokeAllSumTask leftTask new SumTask(array, start, mid); SumTask rightTask new SumTask(array, mid, end); invokeAll(leftTask, rightTask); return leftTask.join() rightTask.join();invokeAll 接收两个子任务后会让第一个任务 fork 出去当前线程执行第二个任务并配合 join调度策略比我手动写的版本更优雅。多个子任务也可以放在集合里一次性传入。6. 避坑实录阻塞、异常、死锁一个比一个阴6.1 千万别在 ForkJoinTask 里做阻塞 IO 或 sleep这是我在项目里踩过最深的一个坑。当时某个数据处理任务里调了一个远程接口我在 compute() 里用了 Thread.sleep 模拟等待结果发现整个 ForkJoinPool 的线程全部卡住其他并行任务一动不动。原因很简单工作窃取机制成立的前提是任务很快能算完线程不会长时间让出 CPU。如果你在任务里 sleep 或者等 IO当前 worker 线程就被真正阻塞了。它不光不干活还会死死占着自己队列里的任务别人想偷都偷不到。极端情况下池里的线程数少于阻塞任务数整个池直接瘫痪。结论ForkJoinPool 只适合 CPU 密集型任务。如果有阻塞操作请拆出来用其他线程池或者把阻塞部分异步化。6.2 异常被吞了怎么办ForkJoinTask 的子任务如果抛出异常异常不会直接抛到调用者那边而是会被封装在任务内部。如果你不处理问题会非常隐蔽。处理方式有两类。一是调用 task.get()它会在 future 风格里抛出 ExecutionException能拿到真正的异常信息。二是自定义重写 setRawResult 或 onCompletion捕获内部异常。try { result leftTask.join(); // 只拿返回值 } catch (Exception e) { // 这里往往拿不到原始异常 } try { result leftTask.get(); // 会包装 ExecutionException } catch (ExecutionException e) { Throwable cause e.getCause(); // 这才是真正的根因 }join() 在遇到异常时表现比较“安静”可能直接返回 null 或抛出一个被包装的 RuntimeException。做线上问题排查时记得先检查 getCause()。6.3 别用并行流和自建 ForkJoinPool 混在一个池里前面提过 commonPool() 是全局共享的。如果代码里既有 parallelStream又有自定义 ForkJoinPool千万注意两个池是互相隔离的不会自动协调。大量占用 commonPool 的并行流加上你提交的密集任务会让 JVM 里的线程总数大幅上升上下文切换成本飙升最后所有任务一起变慢。一个比较稳妥的做法重要且可控的任务自己 new ForkJoinPool并且用完之后 shutdown。不重要的批量计算再考虑并行流。不要在同一个请求链路里既并行流又自定义池混着用很难排查性能问题。6.4 managedBlock阻塞操作的官方补救方案如果实在必须在池内做一定程度的等待ForkJoinPool 提供了一个 managedBlock 接口来自动补充线程。它在检测到某线程可能要阻塞时会临时增加一个补偿线程来维持池的并行度。但请把它当作“补救”而不是“常规手段”能用它解决的往往是短等待而不是长 IO 或死循环。这个接口用得很少但面试里偶尔会问。理解它的存在意义至少能证明你不是只知道 fork 和 join。7. 观察与调优想知道池里发生了什么不能靠猜7.1 用监控 API 感知池的真实状态ForkJoinPool 自带了一些监控方法虽然不是特别丰富但足够看个大概getPoolSize()当前池中的工作线程数。getActiveThreadCount()正在执行任务的线程数。getStealCount()其他线程偷走任务的次数。这个数值猛增说明任务拆分不均衡或者负载波动大。getQueuedTaskCount()当前队列中排队任务数如果长期很大说明任务拆得太碎。getRunningThreadCount()正在“运行中”而非阻塞的线程数。线上排查时我会先看 getActiveThreadCount 和 getStealCount。如果线程数满但 getStealCount 极低说明拆分逻辑有问题任务树太深大家都闷头算自己的那一块不互相帮衬。7.2 观察并行流底层的实用技巧无法直接访问 commonPool 内部的队列但可以通过 ForkJoinPool.commonPool() 拿到池对象一样能调用上面的监控方法。建议把 commonPool 各个指标定期打点一旦发现 getQueuedTaskCount 持续走高就该检查是不是有哪段并行流被滥用或者嵌套了。嵌套并行流也是常见的性能黑洞。比如外层集合用了 parallelStream内层循环又用了 parallelStreamForkJoinPool 的线程数并不会自动翻倍它会用同一批线程去执行嵌套任务。线程等待关系一旦拉长轻则性能下降重则死锁。8. 适合 ForkJoinPool 的场景与不适合的场景8.1 典型适合场景最适合 ForkJoinPool 的是那种可递归拆分、任务与任务之间相对独立、且计算密集的算法数组/集合的归并排序、快速排序大型矩阵运算爬虫或遍历中对每个节点做独立计算再逐级汇总结果图像处理里对像素块的并行处理这些场景里任务拆完以后每个子任务只需要处理自己那一小块数据不需要频繁跨线程通信非常适合窃取调度。8.2 不适合的场景反过来如果是高频 IO、数据库操作、远程调用、包含随机 sleep 的工作流ForkJoinPool 都帮不上忙反而变成负担。拿它做网络请求库的底层调度基本属于“开着法拉利去耕田”花架子大于实际价值。另外还要强调并不是所有递归都适合分治。如果子任务之间有共享的可变状态比如多个子任务同时累加同一个计数器那就要额外加锁或 CAS分治的优势会被同步开销抵消大半。这种情况下先想想能不能改成不可变数据或原子变量再做并行化。9. 我自己测试下来最值得记住的三件事第一fork 和 join 不是银弹。拆得越碎不见得就越快控制阈值、减少无意义的任务对象才是性能的关键。我见过太多人把阈值设成 1结果性能比单线程还差最后还怪 ForkJoinPool 不行。第二任务内千万不要混入阻塞操作。这是 ForkJoinPool 最大的禁忌。ForkJoinPool 的线程池是“轻量调度”的典范让它去扛线程 sleep、IO 等待它回馈给你的就是进程假死。第三并行流的底层就是 ForkJoinPool 的 commonPool不要滥用。用的时候要想着它和全 JVM 共享别人也在用这池子。某个无心的并行流可能会拖垮另一处关键业务的计算。如果你能把分治思想、双端队列、工作窃取这三个词串成一条线来理解 ForkJoinPool再遇到并发性能问题脑子里会有一个非常清晰的排查路径先看任务拆分是不是合理再看池子线程的使用率最后看队列窃取情况而不是像无头苍蝇一样乱加线程数。ForkJoinPool 的魅力在于它用极简的抽象解决了一个相当复杂的工程问题既要支持递归依赖又要保持高吞吐。理解了它你再去看那些并发框架的调度设计会有种豁然开朗的感觉。
ForkJoinPool 这个名字听上去好像很底层但只要用过 Java 并行流或者写过分治算法你八成已经和它打过交道。很多同学把 parallelStream 当成魔法一样用任务一丢就完事遇到性能忽高忽低、线程卡死或者 CPU 跑不满就完全没了头绪。问题往往就出在没搞懂背后的 ForkJoinPool。这篇文章不打算做源码逐行注释更想从“设计者为什么要这么做”的角度把分治思想和工作窃取算法这两件事拆开揉碎讲清楚。我会用实际能跑的代码、调参的经验、以及我踩过的几个坑帮你在日常项目里真正把 ForkJoinPool 用明白。1. ForkJoinPool 到底是什么它在并发库里处在什么位置1.1 传统线程池在“大任务拆小任务”场景下的短板Java 并发这块大家用得最多的就是 ThreadPoolExecutor。它的模型是你提交一批独立任务线程池用固定数量的线程去消费一个共享队列。每个任务之间相互独立、互不等待这种场景下 ThreadPoolExecutor 表现非常好。但如果你面对的是一个可以递归拆分的计算任务比如“算 0 到 100 万的和”天然思路是切成两半、四半、八半让不同线程分别算最后汇总。用 ThreadPoolExecutor 怎么做你把每个子任务都 submit 到池里然后主线程 future.get() 等待结果。子任务又会继续拆分子子任务再次 submit。任务越拆越多线程池的队列被反复塞入微小任务线程切来切去尤其是父任务要等子任务返回会大量占用线程资源白白等待。线程池里一个线程可能在 get() 上阻塞导致活跃线程数量虚高真正干活儿的反而没几个。这就是 ForkJoinPool 出现的核心原因它要支持的不是“一批独立任务”而是“一个可以递归分裂且互相之间有依赖关系”的任务树。1.2 一个池子、两类灵魂分治 窃取ForkJoinPool 之所以能在 JDK 7 加入、并在 JDK 8 成为并行流底层是因为它同时解决了两件事。第一件事是拆分任务通过 fork() 把子任务异步甩出去通过 join() 等待子任务结果。这对应着“分治思想”里的分和合。第二件事是负载均衡一个任务被拆开后可能某些子任务特别快某些特别慢。如果每个线程各守一个队列很快就会出现有人忙死、有人闲死。工作窃取算法让空闲线程去“偷”别人的任务来做从而让 CPU 尽可能被占满。ForkJoinPool 本质上就是一个特殊的线程池它维护的 worker 线程数量默认和 CPU 核数相关每个 worker 维护自己的双端任务队列。这个设计听着简单但里面的门道不少我后面详细展开。2. 分治思想先学会把任务拆到“不用再拆”2.1 怎么用递归来定义一个大任务分治的核心是把一个规模为 N 的问题拆成若干个规模更小的同类问题递归下去直到规模小到可以直接求解然后逐层合并。以归并排序举例对数组 [5, 2, 9, 1, 7, 6] 排序可以拆成左半边 [5, 2, 9] 和右半边 [1, 7, 6]各自排序后再合并。ForkJoinPool 里这种任务被封装成 ForkJoinTask。你通常不直接继承 ForkJoinTask而是继承它的两个现成子类RecursiveAction任务没有返回值典型场景是数组排序、遍历改写。RecursiveTask任务有返回值典型场景是和、最大值、统计类计算。这两个类都只有一个必须实现的抽象方法 compute()。你在 compute() 里判断当前任务够不够小够小就直接算不够小就继续拆。2.2 阈值拆到哪一层才停分治最关键的“度”就是阈值THRESHOLD。阈值太大会导致单个任务依然很大多线程没充分用起来退化成串行阈值太小会导致子任务数量爆炸线程间的协调开销超过了计算本身的收益。举个例子对一个包含 1000 万元素的数组求和直接 fork 到单元素级别会产生约 2000 万个任务对象任务调度压力巨大结果大概率比单线程 for 循环还慢。阈值怎么选经验和基准测试缺一不可。我一般先按“每个任务至少干 10000 到 100000 次简单操作”为标准来初选然后用不同阈值对照跑几遍挑出耗时最低的。具体数值没有通解和 CPU 缓存、内存带宽、任务本身的复杂度都有关。记住一个原则任务拆分和合并的开销必须远小于任务本身的计算量。3. 工作窃取算法一个巧妙到让人拍大腿的负载均衡机制3.1 双端队列任务不是排队而是“抢活”ForkJoinPool 和 ThreadPoolExecutor 在队列设计上有个根本区别。ThreadPoolExecutor 是多个线程共享一个阻塞队列ForkJoinPool 是每个工作线程worker拥有自己的双端队列deque。当线程 A 执行任务 T1T1 通过 fork() 拆出子任务 T1.1、T1.2 时这两个子任务不会丢到一个全局队列而是直接塞到线程 A 自己的队列头部。线程 A 继续往下执行遇到 join() 时会从自己的队列头部取出任务来处理。注意这里用的是 LIFO后进先出也就是说最新拆出来的子任务会被优先执行。为什么因为刚拆出来的子任务的数据大概率还在 CPU 缓存里现取现用缓存命中率最高。其他线程呢它们如果自己的队列空了就去别的线程的队列尾部“偷”任务。这个操作是从尾部取和生产端头部、消费端头部都不冲突只需要在偷取时加一点点同步即可。这种设计叫双端队列结合工作窃取。3.2 为什么窃取能提升整体吞吐量没有工作窃取的话如果任务拆分得不均匀某个线程的队列里堆了一堆任务另一个线程却空转CPU 利用率就上不去。工作窃取让“闲人”主动跑到“忙人”那里分担任务。窃取的粒度是整个任务块而不是单条 CPU 指令因此摊薄下来的同步开销极低。我用一个生活化的类比食堂打饭窗口。如果每个窗口前都固定排一队人某个窗口的厨师动作慢队伍越排越长而旁边的窗口已经没人了厨师在聊天。工作窃取就是允许这个闲着的厨师直接从旁边窗口的队尾拉几个人过来打饭。这不仅让做饭快的窗口能多干活也让闲着的人不至于白拿工资。4. 核心类与参数难点别等报错了才回头学4.1 ForkJoinTask 的三种操作模式ForkJoinTask 最核心的方法就三个fork()异步执行当前任务。注意在 ForkJoinPool 里fork() 并不等于新开一个操作系统线程而是把当前任务放入当前 worker 的队列由同一个 worker 或其他空闲 worker 后续执行。这是一种轻量级调度。join()等待任务返回结果。如果当前线程就是执行该任务的线程它会直接从队列里取任务继续干活而不是傻等。这个设计叫“任务内联执行”。invoke()在当前线程里同步执行任务等价于 fork join 的简化写法。有个初学者很容易搞错的点join() 不是阻塞等待它是一种紧密耦合的协作机制。如果 A 任务 join 了 B 任务而 B 还没开始跑A 所在的 worker 不会干等着而是会去执行其他任务直到 B 的结果就绪。这个机制保证了线程不会因为依赖关系而闲置。4.2 parallelism 和 commonPool到底该怎么设ForkJoinPool 的构造参数中最核心的是 parallelism。它决定池里工作线程的数量。如果不填默认值是 CPU 核心数减一。这个“减一”是因为 main 线程本身也会参与任务执行所以池里不需要留一个专门的线程去配合它。parallelism 不是越大越好。如果你的任务是 CPU 密集型设成核数或核数减一是最稳的。设多了线程切换开销反而拖慢速度。如果任务里包含 IO 或阻塞操作那 ForkJoinPool 并不适合你应该另起专门的线程池。另外JDK 8 之后所有并行流默认使用 ForkJoinPool.commonPool()它是 JVM 级别共享的池。如果你在同一个 JVM 里到处用并行流又提交了重量级自定义任务大家会一起抢这些线程很容易互相拖垮。这也是很多“并行流性能诡异”问题的根源。5. 从入门到实战一个可落地的数组求和案例5.1 最基础的 RecursiveTask 实现我先写一个最经典的求和案例你可以直接拿去跑import java.util.concurrent.RecursiveTask; import java.util.concurrent.ForkJoinPool; public class SumTask extends RecursiveTaskLong { private static final int THRESHOLD 10_000; private final long[] array; private final int start; private final int end; public SumTask(long[] array, int start, int end) { this.array array; this.start start; this.end end; } Override protected Long compute() { int length end - start; if (length THRESHOLD) { long sum 0; for (int i start; i end; i) { sum array[i]; } return sum; } int mid start (end - start) / 2; SumTask leftTask new SumTask(array, start, mid); SumTask rightTask new SumTask(array, mid, end); leftTask.fork(); long rightResult rightTask.compute(); long leftResult leftTask.join(); return leftResult rightResult; } public static void main(String[] args) { long[] input new long[10_000_000]; for (int i 0; i input.length; i) { input[i] i 1; } ForkJoinPool pool new ForkJoinPool( Runtime.getRuntime().availableProcessors() - 1 ); long startTime System.currentTimeMillis(); Long result pool.invoke(new SumTask(input, 0, input.length)); long endTime System.currentTimeMillis(); System.out.println(结果: result , 耗时: (endTime - startTime) ms); pool.shutdown(); } }注意我在 compute() 里的拆分技巧leftTask.fork() 将左半部分异步丢出去右半部分直接在当前线程里 compute()然后再 join 左半部分。这么做比“两边同时 fork 再同时 join”更高效因为当前线程避免了一次不必要的队列调度直接参与了右半边的计算。5.2 阈值调优的实操笔记我分别用 1000、10000、100000 三个阈值跑过这个程序在 8 核 CPU 上结果大致是阈值拆分任务数约耗时ms100020000 个左右大幅增加任务管理开销明显100002000 个左右最优区间100000200 个左右接近串行线程未充分利用阈值过低时ForkJoinPool 会频繁执行 fork 和 join大量短命任务在队列里进进出出得不偿失。阈值过高拆分不到足够的子任务多核优势发挥不出来。所以调优方向永远只有一个在实际数据规模和真实 CPU 环境下做基准测试别拍脑袋设值。5.3 一个小技巧用 invokeAll 简化 fork 双分支上面的代码为了展示 fork/join 的整个过程我手动处理了两边。日常开发中两个子任务同时拆的场景可以直接用 ForkJoinTask.invokeAllSumTask leftTask new SumTask(array, start, mid); SumTask rightTask new SumTask(array, mid, end); invokeAll(leftTask, rightTask); return leftTask.join() rightTask.join();invokeAll 接收两个子任务后会让第一个任务 fork 出去当前线程执行第二个任务并配合 join调度策略比我手动写的版本更优雅。多个子任务也可以放在集合里一次性传入。6. 避坑实录阻塞、异常、死锁一个比一个阴6.1 千万别在 ForkJoinTask 里做阻塞 IO 或 sleep这是我在项目里踩过最深的一个坑。当时某个数据处理任务里调了一个远程接口我在 compute() 里用了 Thread.sleep 模拟等待结果发现整个 ForkJoinPool 的线程全部卡住其他并行任务一动不动。原因很简单工作窃取机制成立的前提是任务很快能算完线程不会长时间让出 CPU。如果你在任务里 sleep 或者等 IO当前 worker 线程就被真正阻塞了。它不光不干活还会死死占着自己队列里的任务别人想偷都偷不到。极端情况下池里的线程数少于阻塞任务数整个池直接瘫痪。结论ForkJoinPool 只适合 CPU 密集型任务。如果有阻塞操作请拆出来用其他线程池或者把阻塞部分异步化。6.2 异常被吞了怎么办ForkJoinTask 的子任务如果抛出异常异常不会直接抛到调用者那边而是会被封装在任务内部。如果你不处理问题会非常隐蔽。处理方式有两类。一是调用 task.get()它会在 future 风格里抛出 ExecutionException能拿到真正的异常信息。二是自定义重写 setRawResult 或 onCompletion捕获内部异常。try { result leftTask.join(); // 只拿返回值 } catch (Exception e) { // 这里往往拿不到原始异常 } try { result leftTask.get(); // 会包装 ExecutionException } catch (ExecutionException e) { Throwable cause e.getCause(); // 这才是真正的根因 }join() 在遇到异常时表现比较“安静”可能直接返回 null 或抛出一个被包装的 RuntimeException。做线上问题排查时记得先检查 getCause()。6.3 别用并行流和自建 ForkJoinPool 混在一个池里前面提过 commonPool() 是全局共享的。如果代码里既有 parallelStream又有自定义 ForkJoinPool千万注意两个池是互相隔离的不会自动协调。大量占用 commonPool 的并行流加上你提交的密集任务会让 JVM 里的线程总数大幅上升上下文切换成本飙升最后所有任务一起变慢。一个比较稳妥的做法重要且可控的任务自己 new ForkJoinPool并且用完之后 shutdown。不重要的批量计算再考虑并行流。不要在同一个请求链路里既并行流又自定义池混着用很难排查性能问题。6.4 managedBlock阻塞操作的官方补救方案如果实在必须在池内做一定程度的等待ForkJoinPool 提供了一个 managedBlock 接口来自动补充线程。它在检测到某线程可能要阻塞时会临时增加一个补偿线程来维持池的并行度。但请把它当作“补救”而不是“常规手段”能用它解决的往往是短等待而不是长 IO 或死循环。这个接口用得很少但面试里偶尔会问。理解它的存在意义至少能证明你不是只知道 fork 和 join。7. 观察与调优想知道池里发生了什么不能靠猜7.1 用监控 API 感知池的真实状态ForkJoinPool 自带了一些监控方法虽然不是特别丰富但足够看个大概getPoolSize()当前池中的工作线程数。getActiveThreadCount()正在执行任务的线程数。getStealCount()其他线程偷走任务的次数。这个数值猛增说明任务拆分不均衡或者负载波动大。getQueuedTaskCount()当前队列中排队任务数如果长期很大说明任务拆得太碎。getRunningThreadCount()正在“运行中”而非阻塞的线程数。线上排查时我会先看 getActiveThreadCount 和 getStealCount。如果线程数满但 getStealCount 极低说明拆分逻辑有问题任务树太深大家都闷头算自己的那一块不互相帮衬。7.2 观察并行流底层的实用技巧无法直接访问 commonPool 内部的队列但可以通过 ForkJoinPool.commonPool() 拿到池对象一样能调用上面的监控方法。建议把 commonPool 各个指标定期打点一旦发现 getQueuedTaskCount 持续走高就该检查是不是有哪段并行流被滥用或者嵌套了。嵌套并行流也是常见的性能黑洞。比如外层集合用了 parallelStream内层循环又用了 parallelStreamForkJoinPool 的线程数并不会自动翻倍它会用同一批线程去执行嵌套任务。线程等待关系一旦拉长轻则性能下降重则死锁。8. 适合 ForkJoinPool 的场景与不适合的场景8.1 典型适合场景最适合 ForkJoinPool 的是那种可递归拆分、任务与任务之间相对独立、且计算密集的算法数组/集合的归并排序、快速排序大型矩阵运算爬虫或遍历中对每个节点做独立计算再逐级汇总结果图像处理里对像素块的并行处理这些场景里任务拆完以后每个子任务只需要处理自己那一小块数据不需要频繁跨线程通信非常适合窃取调度。8.2 不适合的场景反过来如果是高频 IO、数据库操作、远程调用、包含随机 sleep 的工作流ForkJoinPool 都帮不上忙反而变成负担。拿它做网络请求库的底层调度基本属于“开着法拉利去耕田”花架子大于实际价值。另外还要强调并不是所有递归都适合分治。如果子任务之间有共享的可变状态比如多个子任务同时累加同一个计数器那就要额外加锁或 CAS分治的优势会被同步开销抵消大半。这种情况下先想想能不能改成不可变数据或原子变量再做并行化。9. 我自己测试下来最值得记住的三件事第一fork 和 join 不是银弹。拆得越碎不见得就越快控制阈值、减少无意义的任务对象才是性能的关键。我见过太多人把阈值设成 1结果性能比单线程还差最后还怪 ForkJoinPool 不行。第二任务内千万不要混入阻塞操作。这是 ForkJoinPool 最大的禁忌。ForkJoinPool 的线程池是“轻量调度”的典范让它去扛线程 sleep、IO 等待它回馈给你的就是进程假死。第三并行流的底层就是 ForkJoinPool 的 commonPool不要滥用。用的时候要想着它和全 JVM 共享别人也在用这池子。某个无心的并行流可能会拖垮另一处关键业务的计算。如果你能把分治思想、双端队列、工作窃取这三个词串成一条线来理解 ForkJoinPool再遇到并发性能问题脑子里会有一个非常清晰的排查路径先看任务拆分是不是合理再看池子线程的使用率最后看队列窃取情况而不是像无头苍蝇一样乱加线程数。ForkJoinPool 的魅力在于它用极简的抽象解决了一个相当复杂的工程问题既要支持递归依赖又要保持高吞吐。理解了它你再去看那些并发框架的调度设计会有种豁然开朗的感觉。
