forkjoinpool中抛出的异常会被捕获并封装为任务失败结果，需通过join()或get()显式获取：recursivetask调用get()/join()抛出executionexception，getcause()返回原始异常；recursiveaction同理；invokeall()任一子任务失败即抛executionexception；忽略join()/get()将导致异常静默丢弃。
在 ForkJoinPool 中，throw 抛出的异常不会像普通线程那样直接“穿透”到调用方，而是被封装、捕获并需主动获取——这是 Fork-Join 框架的设计特性，不是 bug。
异常会被捕获并存入任务结果中
ForkJoinPool 的 Worker 线程执行 ForkJoinTask（如 RecursiveAction 或 RecursiveTask）时，若任务中使用 throw 抛出未捕获异常，框架会自动捕获该异常，并将其作为任务的“失败结果”保存。此时：
- 对于
RecursiveTask<v></v>：调用get()或join()时，抛出ExecutionException，其getCause()返回原始异常； - 对于
RecursiveAction（无返回值）：同样通过join()或get()触发异常传递； - 异常不会跨线程自动传播，也不会中断其他并行子任务（除非显式检查或取消）。
正确获取和处理异常的典型方式
必须显式等待任务完成并检查结果，不能忽略 join() 或 get() 调用：
- 用
task.join()（推荐，轻量，阻塞当前 fork-join 线程）； - 或
task.get()（支持超时，抛出InterruptedException和ExecutionException）； - 若在
compute()内部调用子任务的invokeAll()，它会自动等待全部完成，任一子任务失败会导致整个调用抛出ExecutionException（需 try-catch 处理）； - 避免只调用
fork()就结束——这不等待也不传播异常，相当于“静默丢弃”。
自定义异常传递与上下文增强
原始异常可能丢失调用栈上下文（尤其多层 fork/join），可主动包装再抛出：
- 在
compute()中 catch 异常后，用throw new RuntimeException("in subtask: " + originalMsg, cause)包装； - 使用
CompletableFuture包装 ForkJoinTask（如supplyAsync(task::invoke, pool)），配合exceptionally()统一处理； - 记录日志时，建议打印
task.getException()（返回Throwable，null 表示未失败），比依赖get()的异常更可控。
常见误区与规避建议
很多问题源于对异步语义的误判：
- 不要在 compute() 中仅 throw 却不 join 子任务 —— 异常无法向上冒泡；
- 不要用普通 try-catch 吞掉所有异常却不 re-throw 或标记失败 —— 这会让父任务误判为成功；
- 避免在 parallelStream() 底层使用的 ForkJoinPool 中自行 throw 检查异常（如 Exception） —— 它必须是 RuntimeException 或 Error，否则编译不通过；
- 调试时可用
ForkJoinPool.setCommonPoolParallelism(1)降低并发度，让异常栈更清晰。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
