Java线程池中任务异常默认静默丢失，因Runnable异常由未配置的UncaughtExceptionHandler忽略，Callable异常需显式调用Future.get()才能暴露；正确捕获方式包括任务内try-catch、自定义ThreadFactory设置异常处理器、重写afterExecute()钩子方法。
Java线程池中任务抛出的异常，**默认不会被主线程捕获，也不会打印堆栈，容易静默丢失**。这是开发者常踩的坑——看似任务执行了，实则因异常中断却毫无感知。
为什么线程池里的异常经常“消失”？
ThreadPoolExecutor 执行任务时，若 Runnable 任务中抛出未检查异常（如 RuntimeException），线程池会捕获它并调用 Thread.getUncaughtExceptionHandler() 处理；但默认的 handler 什么也不做。而 Callable 任务的异常会被包装进 ExecutionException，**必须显式调用 get() 才能暴露**。
正确捕获 Runnable 任务异常的三种方式
-
在任务内部 try-catch：最直接，适合业务逻辑明确、可预判异常类型的场景
例：new Runnable() { public void run() { try { doWork(); } catch (Exception e) { log.error("task failed", e); } } } -
自定义 ThreadFactory 设置 UncaughtExceptionHandler：统一兜底，推荐用于全局异常监控
例：new ThreadFactoryBuilder().setUncaughtExceptionHandler((t, e) -> log.error("thread {} crashed", t.getName(), e)).build() -
重写 ThreadPoolExecutor.afterExecute()：钩子方法，可同时处理正常返回和异常结束的任务
注意：需判断thrown != null才是异常情况，且该方法在任务执行完后由工作线程调用
Callable 任务异常必须主动“拉取”
submit(Callable) 返回 Future，它的 get() 方法是异常曝光的唯一出口。不调用 get()，异常就永远藏在 Future 内部。
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 同步等待结果时，直接在 try-catch 中调用 get()
- 异步场景（如用 CompletableFuture 包装），确保链式调用中包含
handle()或exceptionally()捕获异常 - 批量提交后，记得遍历 Future 列表，逐个调用 get() —— 即使只关心是否完成，也建议设超时（
get(5, TimeUnit.SECONDS)）避免无限阻塞
避免线程池因异常持续退化
如果任务频繁抛异常且未处理，可能引发连锁问题：
立即学习“Java免费学习笔记（深入）”；
- 核心线程因未捕获异常退出后，默认会重建（取决于 allowCoreThreadTimeOut），但若异常持续，线程反复创建销毁，影响性能
- 使用无界队列（如 LinkedBlockingQueue）时，异常任务无法消费，队列不断积压，最终 OOM
- 建议：关键任务加监控埋点；线程池配置合理的拒绝策略（如 CallerRunsPolicy）；对不可信外部调用做隔离和熔断
基本上就这些。关键是记住：线程池不替你处理异常，它只负责调度。异常在哪抛出，就得在哪捕获或显式暴露。
