线程池里的异常去哪了？execute 和 submit 不是一回事

这个问题很容易在监控里伪装成"任务提交成功"：任务明明抛了异常，线程池却还在接活，业务日志也没出现堆栈。

通常不是异常没发生，而是代码把 execute 换成 submit 后，异常的出口也换了。

先看一段最小代码：

java 复制代码

ExecutorService pool = Executors.newFixedThreadPool(1);

pool.execute(() -> {
    throw new IllegalStateException("execute failed");
});

Future<?> future = pool.submit(() -> {
    throw new IllegalStateException("submit failed");
});

这两个任务都确实失败了，但观察结果不同。

execute：异常会离开 worker

ThreadPoolExecutor 的 worker 执行任务时，直接调用 task.run()。如果任务抛出异常，线程池会先调用 afterExecute(task, ex)，再把异常继续抛出。

所以 execute 这条路径有三个明显信号：

afterExecute 能直接拿到 Throwable
线程的 UncaughtExceptionHandler 有机会收到异常
当前 worker 会结束，线程池仍在运行且需要维持线程数时会补充 worker

这里的"线程结束"不是线程池挂了。线程池本身还在，只是执行这次任务的 worker 退出了。

submit：异常被 FutureTask 收起来

submit 不会把原始 Runnable 直接交给 worker。它会把任务包装成 FutureTask，再走 execute。

FutureTask.run() 内部会捕获任务抛出的 Throwable，调用 setException 保存下来。对 worker 来说，FutureTask.run() 已经正常返回了，因此：

afterExecute 收到的 Throwable 通常是 null
未捕获异常处理器不会收到这次业务异常
异常要通过 future.get() 取回，表现为 ExecutionException

java 复制代码

Future<?> future = pool.submit(() -> {
    throw new IllegalStateException("submit failed");
});

try {
    future.get();
} catch (ExecutionException e) {
    Throwable cause = e.getCause();
    System.err.println("task failed: " + cause);
}

注意是 getCause()。外层 ExecutionException 只是在说"Future 对应的计算失败了"，真正的业务异常在 cause 里。

监控钩子为什么经常漏报

很多项目会继承线程池，重写 afterExecute 打日志：

java 复制代码

@Override
protected void afterExecute(Runnable r, Throwable t) {
    super.afterExecute(r, t);

    if (t == null && r instanceof Future<?> future && future.isDone()) {
        try {
            future.get();
        } catch (CancellationException e) {
            t = e;
        } catch (ExecutionException e) {
            t = e.getCause();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    if (t != null) {
        log.error("async task failed", t);
    }
}

这段逻辑的关键不是"再调一次线程池 API"，而是承认 submit 的异常已经被 Future 保存了。只有把已完成的 Future 解包，监控才看得到真实原因。

如果业务根本不需要结果，也可以直接用 execute，让异常沿 worker 路径暴露出来。要是必须用 submit，就把 Future 当成任务结果和错误的唯一收件箱，别只看提交方法有没有返回。

排查这类问题时，先问一句：这段异步代码最后有没有人调用 get()？没有的话，submit 返回得再快，也可能只是把异常藏得更深。