主线程无法自动感知子线程抛出的runtimeexception，需通过future+callable主动拉取、uncaughtexceptionhandler被动接收或共享状态主动检查三种机制传递异常。
主线程无法自动感知子线程抛出的 RuntimeException，因为 Java 的线程模型中异常不跨线程传播。子线程崩溃时，主线程照常运行，既不会中断，也不会收到通知——除非你主动建立传递通道。关键不是“能不能捕获”，而是“用什么机制把异常从子线程‘送’到主线程手里”。
方案一：用 Future + Callable 主动拉取异常
这是最可控、最推荐的方式，适用于需要结果或明确知道子线程执行逻辑的场景。
- 把子线程任务改写为
Callable<t></t>（而非Runnable），让其能返回值或抛出异常； - 通过
ExecutorService.submit()提交，获得Future<t></t>对象； - 主线程调用
future.get()时，若子线程已抛异常，会封装为ExecutionException并在主线程中抛出，可直接catch处理； - 注意：
get()是阻塞调用，若子线程未结束，主线程会等待；超时重载版可避免无限挂起。
方案二：设置 UncaughtExceptionHandler 被动接收异常
这是轻量级兜底方案，适合监控、日志、资源清理等通用异常响应，不依赖任务返回值。
- 每个线程可单独设置处理器：
thread.setUncaughtExceptionHandler((t, e) -> { ... })； - 也可全局设置：
Thread.setDefaultUncaughtExceptionHandler(...)，对后续所有未设处理器的线程生效； - 处理器中拿到的
e就是原始的RuntimeException，可记录、告警、存入共享变量供主线程检查； - ⚠️ 注意：该机制仅触发一次，且不改变主线程流程——它只是“通知”，不是“同步捕获”，如需主线程据此决策（比如终止流程），得配合其他通信手段（如
AtomicReference<throwable></throwable>）。
方案三：共享状态 + 主动检查（手动协作）
适合需要精细控制协作时机、或无法修改线程创建方式（如第三方库启动的线程）的场景。
- 定义一个线程安全的容器，例如
AtomicReference<throwable></throwable>或BlockingQueue<throwable></throwable>； - 子线程在
catch块中将异常存入该容器（即使没显式try-catch，也可在UncaughtExceptionHandler中存）； - 主线程在关键节点（如
join()后）检查该容器是否有异常，有则处理； - 优势在于完全自主、无框架依赖；缺点是需自行协调时序，容易遗漏检查点。
为什么不建议依赖 try-catch 包裹 start()？
因为 thread.start() 只是发起调度，不执行任务体。子线程的 run() 或 call() 在另一个执行流中运行，主线程的 try-catch 作用域对其无效——就像你不能用厨房里的锅盖盖住隔壁房间烧开的水壶。
