ForkJoinPool子任务异常遵循首次异常优先传播原则，任一子任务抛出未捕获异常即终止任务链并向上抛出ExecutionException；不自动合并异常，需手动捕获并聚合。
ForkJoinPool 中子任务异常的汇总处理，不是简单地“收集所有异常”，而是遵循首次异常优先传播原则——只要任一子任务抛出未捕获异常，整个任务链就会提前终止，并将该异常作为最终结果向上抛出。它不支持自动合并多个异常，也不提供内置的异常聚合机制。
异常传播机制：fork/join 不做兜底，只做穿透
ForkJoinTask 的 join() 方法在子任务异常完成时，会直接封装为 ExecutionException（包装原始异常）并抛出；若调用 invoke() 或 submit().get()，同样触发该行为。关键点在于：
- 异常一旦发生，
fork()后续的其他子任务可能仍在运行，但调用join()时只要遇到一个已异常完成的任务，就立即抛出，不会等待其余任务结束 - 没有“等全部子任务跑完再汇总所有异常”的默认逻辑；ForkJoinPool 不维护异常集合，也不重试或降级
- 若父任务在
compute()中未显式捕获子任务异常，异常会沿调用栈向上传递，最终由ForkJoinPool.invoke()或Future.get()抛出
手动实现异常变量合并的可行路径
如需获取多个子任务各自的异常信息（例如用于日志诊断、批量失败统计），必须主动干预执行流程，常见做法包括：
- 在每个子任务的
compute()中用try-catch捕获异常，将异常对象或描述存入线程安全容器（如ConcurrentLinkedQueue<Throwable>），再返回占位结果（如null或特殊标记值） - 父任务调用
leftTask.fork(); rightTask.fork();后，分别调用leftTask.join()和rightTask.join()并各自catch ExecutionException，把捕获的e.getCause()加入本地异常列表 - 合并阶段不再直接返回计算值，而是返回一个结构化结果类，例如：
class TaskResult<T> { T value; List<Throwable> errors; }
避免常见陷阱：异步+异常=不可靠顺序
以下写法存在隐患：
-
leftTask.fork(); rightTask.fork(); leftTask.join(); rightTask.join();—— 若leftTask先异常，rightTask.join()可能根本没机会执行，导致遗漏其异常 - 依赖
ForkJoinPool.commonPool()执行带异常风险的任务 —— 公共池被全局共享，异常可能干扰其他模块，且无法定制异常处理器 - 在
RecursiveTask中对join()结果不做判空或类型检查，导致NullPointerException掩盖原始业务异常
增强健壮性的推荐配置
提升异常可观测性与可控性，可结合以下设置：
- 构造
ForkJoinPool时传入UncaughtExceptionHandler，用于记录工作线程未捕获的致命异常（如OutOfMemoryError） - 对关键任务启用
setAsyncMode(true)（仅适用于RecursiveAction），降低 join 阻塞带来的异常传播延迟 - 在任务拆分阈值设计中预留容错空间，避免因单个极小任务崩溃导致整棵树回滚；例如：对数据分片加校验，跳过损坏块而非中断整个计算
