Java多线程中未捕获异常默认不传播给主线程，子线程静默终止；需通过UncaughtExceptionHandler、ThreadPoolExecutor.afterExecute或CompletableFuture异常处理机制显式捕获。
Java 多线程中，Thread 默认不会将未捕获异常传播给主线程，一旦子线程抛出 RuntimeException 或其子类（如 NullPointerException、ArrayIndexOutOfBoundsException），线程会静默终止，而调用方完全感知不到——这是绝大多数并发问题排查困难的根源。
未捕获异常默认被吞掉，必须显式设置异常处理器
每个 Thread 都有一个关联的 UncaughtExceptionHandler。默认情况下，它由 ThreadGroup 提供，仅打印堆栈到 System.err，且不中断主线程或通知调度方。
- 全局设置：用
Thread.setDefaultUncaughtExceptionHandler(...)设置所有未显式指定处理器的线程 - 单线程设置：在启动前调用
thread.setUncaughtExceptionHandler(...) - 线程池场景下，
ThreadPoolExecutor的afterExecute(Runnable r, Throwable t)是更可靠的捕获点，因为submit()提交的任务异常会被包装进ExecutionException，而execute()提交的则直接触发异常处理器
Thread thread = new Thread(() -> {
throw new RuntimeException("boom");
});
thread.setUncaughtExceptionHandler((t, e) ->
System.err.println("Thread " + t.getName() + " failed: " + e.getMessage())
);
thread.start();
ExecutorService.submit() 和 execute() 的异常行为完全不同
这是最容易混淆的设计差异：前者把任务包装成 FutureTask，异常被压制在 Future.get() 中；后者直接执行，异常走 UncaughtExceptionHandler 流程。
-
submit(Runnable)→ 返回Future，异常需显式调用future.get()才抛出ExecutionException -
submit(Callable)→ 同样需get()，否则异常永远不浮现 -
execute(Runnable)→ 异常直接触发线程的UncaughtExceptionHandler，不经过Future
ExecutorService exec = Executors.newSingleThreadExecutor();
exec.submit(() -> { throw new RuntimeException("ignored until get()"); });
// 此时无任何输出，也无中断
exec.execute(() -> { throw new RuntimeException("immediately handled by handler"); });
// 若未设 handler，则只打印到 stderr
使用 CompletableFuture 时，异常必须用 exceptionally() 或 handle() 显式处理
CompletableFuture 的链式调用中，任何一步抛出异常都会中断后续 thenApply 等回调，但若没注册异常处理回调，异常就“消失”了——既不打印，也不传播，连日志都看不到。
立即学习“Java免费学习笔记（深入）”；
-
whenComplete()和handle()能同时处理正常结果和异常，推荐优先使用handle()（它支持返回值） -
exceptionally()只在异常时触发，适合兜底返回默认值 - 切忌只写
thenApply就完事，那是典型的“异常黑洞”写法
CompletableFuture.supplyAsync(() -> {
throw new RuntimeException("no one sees this without handling");
}).exceptionally(ex -> {
System.err.println("Caught: " + ex.getMessage());
return "fallback";
}).join();
真正棘手的不是怎么捕获异常，而是多个异步分支、嵌套 CompletableFuture、混合 ExecutorService 和手动 Thread 时，异常路径变得不可预测。这时候靠日志打点 + 统一的 UncaughtExceptionHandler + 所有 Future.get() 加超时和 try-catch，才是稳妥组合。漏掉任意一环，问题就藏进后台静默失败。
