ForkJoinPool不提供统一异常兜底，而是异常穿透：任一子任务抛未捕获异常即封装为ExecutionException抛出，其余任务可能仍在运行；需手动try-catch+结构化结果（如Result<T>）或改用CompletableFuture实现兜底。
ForkJoinPool 本身不提供统一异常兜底机制，它只做异常穿透——哪个子任务先抛出未捕获异常，整个任务就立即失败并向上抛 ExecutionException。所谓“统一异常处理器兜底”，不是框架自动做的，而是你主动设计的容错结构。
明确 ForkJoin 的异常传播本质
ForkJoinPool 不会等所有子任务跑完再汇总错误；也不会重试、降级或静默吞掉异常。parallelStream() 底层用的就是 ForkJoinPool.commonPool()，所以它的行为完全一致：
- 一旦某个分支 compute() 中抛出未捕获异常（比如 RuntimeException），该分支标记为异常完成
- 父任务调用 join() 时，只要遇到一个已异常完成的子任务，立刻封装为 ExecutionException 抛出，其余子任务可能仍在运行但被忽略
- 没有全局“异常处理器”注册点，也没有类似 Spring @ControllerAdvice 那样的拦截机制
实现“兜底”的核心思路：手动捕获 + 结构化结果
要达成“所有任务都执行完、收集全部失败信息、最终统一处理”，必须放弃默认的异常传播链，改用显式错误捕获和结构化返回值：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 每个子任务（包括 map/filter/forEach 等中间操作）不在 lambda 内直接 throw，而是 try-catch 后返回一个包装结果，例如 Result<T> { T data; Throwable error; boolean success; }
- 使用 parallelStream() 时，把原始流元素转为 Result 实例，后续操作都基于 Result 进行（如 flatMap 处理成功/失败路径）
- 最终 collect 成一个 List<Result<T>>，再遍历筛选 error != null 的项，统一记录日志、告警或补偿
替代方案：用 CompletableFuture 替代 parallelStream
如果需要更强的异常控制力（比如超时、回调、组合多个异步操作），ForkJoinPool + Stream 并非最优选。CompletableFuture 更适合构建可兜底的异步流程：
- 用 CompletableFuture.supplyAsync(() -> {...}, pool) 提交每个子任务，每个都独立 try-catch
- 用 CompletableFuture.allOf() 或 CompletableFutureList 汇总所有 Future，再逐个 get() 并捕获 ExecutionException
- 可设置统一 fallback：exceptionally(e -> handle(e)) 或 handle((v, e) -> {...})
- 避免 parallelStream 在静态初始化块中引发死锁（如知识库中提到的类加载 Hang 场景）
避坑提醒：别踩这些常见误区
很多开发者试图用 Thread.setDefaultUncaughtExceptionHandler 或 try-catch 包裹 parallelStream().forEach(...)，这根本无效：
- parallelStream 的任务在 ForkJoinWorkerThread 上执行，其未捕获异常由 ForkJoinTask 自己处理，不走默认异常处理器
- forEach 是终端操作，且无返回值（void），lambda 无法 throws 检查异常，编译都不通过
- 用 submit(Runnable) 提交任务也无法获取异常，必须用 Callable + Future.get()
