Java多线程中子线程未捕获异常默认被静默吞掉；需用setDefaultUncaughtExceptionHandler（仅对Thread有效）、ExecutorService中区分Runnable/Callable异常处理、CompletableFuture显式调用join/get或注册exceptionally/handle，线程池应结合自定义ThreadFactory设置异常处理器。
Java 多线程中，子线程抛出的未捕获异常默认不会传播到主线程，也不会中断 JVM，而是被静默吞掉——这是最常踩的坑。
Thread.setDefaultUncaughtExceptionHandler 用法与限制
这是捕获“未显式 try-catch”的子线程异常的最常用方式，但只对 Thread 实例生效，不适用于 ForkJoinPool 或 Executors 创建的线程池中的任务。
- 必须在子线程启动前设置，否则无效；主线程设置不影响已启动的子线程
- 每个
Thread可单独设置自己的setUncaughtExceptionHandler，优先级高于全局默认处理器 - 示例：
Thread.setDefaultUncaughtExceptionHandler((t, e) -> { System.err.println("线程 " + t.getName() + " 异常：" + e); });
ExecutorService 中 Runnable/Callable 的异常处理差异
Runnable 的异常会被彻底丢弃（除非手动包装），而 Callable 的异常会封装进 ExecutionException，必须调用 get() 才能暴露。
-
submit(Runnable)：异常无法通过Future.get()获取，需靠Thread.UncaughtExceptionHandler捕获 -
submit(Callable)：异常包裹在ExecutionException中，future.get()会抛出它，getCause()才是原始异常 - 使用
invokeAll()时，每个Future都要单独get()，否则异常仍不可见
CompletableFuture 异常传播的隐式陷阱
CompletableFuture 默认不传播异常，除非显式调用 join()、get() 或注册 exceptionally()/handle() 回调。
立即学习“Java免费学习笔记（深入）”；
-
thenApply()、thenAccept()等“非终结”方法中抛异常，会静默终止链路，后续then*不执行，也不报错 - 推荐始终用
exceptionally(Function)或handle(BiFunction)显式处理可能异常 - 若需将异常转为日志+默认值，
exceptionally(e -> { log.error("", e); return defaultValue; })更安全
自定义 ThreadFactory + UncaughtExceptionHandler 组合方案
在线程池场景下，仅靠全局 handler 不够可靠，必须配合 ThreadFactory 为每个新线程绑定 handler。
-
Executors.defaultThreadFactory()不设置异常处理器，需自行包装 - 示例工厂：
ThreadFactory factory = r -> { Thread t = new Thread(r, "my-pool-thread"); t.setUncaughtExceptionHandler((th, ex) -> { log.error("线程 {} 异常终止", th.getName(), ex); }); return t; }; - 传给
new ThreadPoolExecutor(..., factory, ...)才真正生效
真正难处理的不是“怎么捕获”，而是“在哪捕获”——异步链路越长，异常越容易在某一层断掉。别依赖默认行为，凡是有 Future、CompletableFuture、或 ExecutorService.submit() 的地方，都要明确设计异常出口。
