execute()抛异常会立即打印堆栈并终止工作线程；submit()将异常封装进future，不调用get()则静默丢失，必须解包e.getcause()才能获取原始异常。
Java 线程池中，submit() 和 execute() 对异常的捕获行为差异非常关键——不是“要不要捕获”，而是“异常在哪暴露、由谁处理、是否影响线程存活”。
异常是否立即打印堆栈
execute() 提交的任务一旦抛出未捕获异常（如 RuntimeException），会直接触发工作线程的 UncaughtExceptionHandler，默认打印异常堆栈到控制台或日志，并终止该线程；而 submit() 会把异常捕获并封装进 FutureTask 内部，调用方不调用 get() 就完全看不到异常，也不会有任何日志输出。
- execute 场景示例：
executor.execute(() -> { int x = 1 / 0; });→ 控制台立刻输出ArithmeticException堆栈 - submit 场景示例：
Future> f = executor.submit(() -> { int x = 1 / 0; });→ 控制台静默，无任何提示
异常是否中断工作线程
execute() 的异常会导致当前工作线程“当场退出”，线程池随后按需补一个新线程（例如维持核心线程数）；submit() 的异常不会打断线程执行流程，工作线程正常完成任务、归还到池中，稳定性更高，但掩盖了问题。
- execute 异常后：线程死亡 → 可能触发线程重建 → 日志可见 → 容易发现故障点
- submit 异常后：线程存活 → 任务标记为“已完成但失败” → 若不检查 Future，异常等于丢失
异常如何被调用方感知
execute() 没有返回值，调用方无法主动获取异常，也无法取消任务；submit() 返回 Future，必须显式调用 get() 才会以 ExecutionException 包装抛出原始异常，此时才能统一捕获和处理。
- 正确用法：
try { f.get(); } catch (ExecutionException e) { log.error("任务失败", e.getCause()); } - 常见陷阱：只提交、不 get，或忽略 catch 中的
e.getCause()，导致业务异常被吞掉 - 即使是 submit(Runnable)，也要调用 get() 才能确认是否执行成功（返回 null，但异常仍需处理）
该选哪个？看异常是否需要可控可追溯
如果任务失败不影响系统主流程，且你只关心“它跑没跑”，用 execute() 更轻量、异常更透明；如果任务结果重要、需批量等待、要统一兜底或支持重试，必须用 submit()，但务必配套 get() + 异常解包逻辑。
- 适合 execute() 的场景：发日志、推消息、刷新缓存——失败了也无需反馈
- 适合 submit() 的场景：校验多个参数、并行查 DB、聚合计算——必须知道哪几个失败、返回什么错误
- 切忌混用：同一业务中部分用 execute、部分用 submit，会让异常处理策略碎片化，增加排查难度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
