execute()提交任务时异常导致工作线程终止，线程池按需补位；submit()将异常封装进Future，需调用get()才暴露，线程不受影响但异常易被忽略。
用 execute() 提交任务时，若 Runnable 内部抛出未捕获异常（如 RuntimeException），该异常会直接由工作线程抛出，触发线程的 UncaughtExceptionHandler —— 默认行为是打印堆栈并终止当前工作线程；线程池检测到线程死亡后，会按需新建一个线程补位（取决于是否低于核心线程数）。而用 submit() 提交的同一任务，异常不会立即暴露：它被封装进 FutureTask，调用 future.get() 前完全静默，工作线程也不会因此中断。
execute()：异常导致线程“当场退出”
工作线程执行 execute() 提交的 Runnable 时，一旦发生未捕获异常，线程会直接终止。这不是线程池“杀掉”它，而是任务执行流自然崩溃所致。线程池本身不干预，仅在后续分配新任务时发现可用线程不足，才按策略创建替补线程（例如保持核心线程数不变）。
- 异常堆栈会输出到控制台或日志（取决于 JVM 的默认异常处理器）
- 调用方无法捕获该异常，因为 execute() 是 void 方法，也不提供回调机制
- 适合对失败不敏感、无需反馈的场景，如异步日志写入、MQ 发送
submit()：异常被“封存”在 Future 中
submit() 把任务包装为 FutureTask，其 run() 方法内部有 try-catch，异常被捕获后调用 setException() 存入 Future 对象。工作线程正常结束，不会因任务异常而退出。
- 不调用
future.get()就永远看不到异常，也无任何日志输出 - 若忘记检查
future.isDone()或忽略get()抛出的ExecutionException，异常等于丢失 - 即使提交的是 Runnable（
submit(Runnable)），也要调用get()才能感知异常（返回 null，但异常仍需处理）
对线程存活的实际影响对比
关键不在“线程是否还活着”，而在“异常是否可控、可追溯”。execute() 的异常让线程挂掉，但至少暴露了问题；submit() 让线程稳住，却把异常藏起来——表面更稳定，实则更危险。
- 线程存活率：submit() 更高（异常不终结线程），execute() 更低（异常即终止）
- 问题可见性：execute() 异常立即可见；submit() 异常必须主动拉取，否则彻底隐身
- 运维风险：submit() 忽略 Future 是典型隐患，可能导致批量任务静默失败、状态失察
如何兜住两种方式的异常漏网
不能依赖默认行为。推荐组合使用防御手段：
- 为线程池配置自定义
ThreadFactory，在创建线程时设置统一的UncaughtExceptionHandler，确保 execute 异常也能进业务日志 - 对 submit() 任务，强制要求调用方处理
future.get()或至少轮询isDone()+get(0, TimeUnit.NANOSECONDS)避免阻塞 - 在线程池构造时指定拒绝策略为
CallerRunsPolicy，配合日志，让饱和时的异常也回流到调用线程便于捕获
