execute适合提交无返回值的Runnable任务，异常静默处理，不返回Future，轻量高效，适用于日志、监控等“发了就忘”场景。
ExecutorService.execute() 适合提交 Runnable 类型的无返回值任务
直接用 execute() 提交任务，意味着你只要它“跑起来”，不关心结果、也不需要捕获异常（异常会吞掉，除非自定义 ThreadFactory 或 UncaughtExceptionHandler）。它比 submit() 更轻量，没有 Future 开销，适合日志上报、缓存刷新、监控打点这类“发了就忘”的场景。
常见错误是传入 Callable ——execute() 只接受 Runnable，传错会编译失败：
executor.execute(() -> { /* 正确：lambda 实现 Runnable */ });
// executor.execute(() -> "done"); // 编译错误：不能把 Callable<string> 当作 Runnable</string>
- 必须确保任务体不抛出未检查异常，否则异常会被静默吞掉，线程终止，且无日志
- 若需记录异常，应在
run()内部 try-catch，或给线程池配置Thread.UncaughtExceptionHandler - 不要在
execute()后立刻关闭线程池（如调用shutdownNow()），否则任务可能被中断或丢弃
如何安全地向 execute() 传递带参数或状态的任务
Java 8+ 的 lambda 和方法引用让传参变简单，但要注意变量捕获的生命周期。局部变量必须是“事实上的 final”（即声明后不再赋新值）。
示例中 userId 和 logger 都是安全的：
String userId = "u123";
Logger logger = LoggerFactory.getLogger(TaskRunner.class);
executor.execute(() -> {
logger.info("Processing user: {}", userId);
doHeavyWork(userId); // 假设这是个无返回的 void 方法
});
- 避免在 lambda 中修改外部变量（如
userId = "u456"），否则编译报错 - 如果必须动态构造任务对象，优先用匿名内部类或私有静态辅助类，避免无意中持有了大对象引用导致内存泄漏
- 不要在
execute()中直接传this::someMethod，除非确认this不会在任务执行前被销毁（比如 Activity 或 Fragment 已 finish）
execute() 和 submit(Runnable) 的关键区别在哪
表面看两者都能跑 Runnable，但语义和行为不同：
-
execute()：纯异步触发，无返回值，异常静默，不可取消，不参与线程池的统计（如getCompletedTaskCount()不计数它） -
submit(Runnable)：返回Future>，可调用isDone()或cancel()，异常会封装进Future.get()抛出，计入完成任务数 - 性能上
execute()略快，少一次Future对象分配，但差异微乎其微，别为这点优化牺牲可维护性
如果你从没调用过 Future.cancel() 或 Future.get()，那用 execute() 更诚实；反之，哪怕只为了加个超时等待，也该用 submit()。
线程池关闭时，execute() 提交的任务会怎样
取决于关闭方式：
-
shutdown()：已提交的execute()任务仍会执行完，新提交的会被拒绝（抛RejectedExecutionException） -
shutdownNow()：尝试中断所有正在运行的线程（对阻塞 I/O 无效），已提交但未开始执行的execute()任务会被清出队列并返回，**不会执行** - 所以，如果任务有副作用（如发 HTTP 请求、写磁盘），不能依赖
shutdownNow()保证它一定执行
真正可靠的“最后执行”逻辑，得靠 awaitTermination() 配合 shutdown()，再加兜底的同步 fallback —— 这点容易被忽略，尤其在 Spring Boot 应用里自动管理线程池时。
