submit() 返回 future 可获取结果或取消任务，execute() 无返回值且异常易静默；shutdown() 等待任务自然完成，shutdownnow() 尝试中断并清空队列；cachedthreadpool 易因无限建线程导致 oom。
ExecutorService.submit() 和 execute() 的区别在哪
关键差异在于返回值和异常处理方式。submit() 返回 Future，能获取结果或主动取消任务；execute() 无返回值，且任务中未捕获的异常会直接由线程的 UncaughtExceptionHandler 处理，容易静默失败。
常见错误是用 execute() 提交需要结果的任务，导致后续无法判断执行状态或取不到返回值。
- 需要异步结果、超时控制、取消能力 → 用
submit() - 纯“发了就不管”的后台任务（如日志上报、监控打点）→
execute()更轻量 -
submit(Runnable)返回的Future.get()结果为null，不是任务返回值
shutdown() 和 shutdownNow() 到底停不停得干净
两者都不等同于“立即终止所有线程”。shutdown() 拒绝新任务，但会等已提交任务（包括队列里还没开始的）自然完成；shutdownNow() 尝试中断正在运行的线程，并清空任务队列，返回未执行的任务列表。
典型陷阱：调用 shutdownNow() 后立刻 awaitTermination(1, TimeUnit.SECONDS) 就认为线程池已关闭——但若任务没响应中断（比如在做 IO 阻塞、没检查 Thread.interrupted()），线程可能一直卡住。
立即学习“Java免费学习笔记（深入）”；
- 务必在任务逻辑中定期检查中断状态，尤其是循环体或阻塞调用前
-
awaitTermination()返回false表示超时未结束，此时需决定是否强制释放资源 - 不要依赖
shutdownNow()来“杀掉”死循环任务，它只是发中断信号
为什么 CachedThreadPool 在高并发下容易 OOM
Executors.newCachedThreadPool() 使用无界 SynchronousQueue 和默认 Integer.MAX_VALUE 核心线程数，意味着每来一个新任务，只要没空闲线程，就新建线程。线程栈本身占内存（默认 1MB），大量线程会迅速耗尽堆外内存或触发系统级线程创建失败。
线上环境几乎从不直接用这个工厂方法。它适合短生命周期、低吞吐、偶发的异步任务（如 UI 事件响应），而非服务端请求处理。
- 替代方案：用
ThreadPoolExecutor显式构造，设合理corePoolSize、maximumPoolSize和有界队列（如ArrayBlockingQueue） - 拒绝策略别用默认的
AbortPolicy（抛RejectedExecutionException），考虑CallerRunsPolicy或自定义降级逻辑 - JVM 参数
-Xss调小线程栈（如 256k）可缓解，但治标不治本
如何安全地复用 ExecutorService 实例
线程池不是一次性的——它设计初衷就是长期复用。但复用的前提是生命周期管理清晰：不能在任务中调用 shutdown()，也不能让多个模块隐式共享同一个实例却各自试图关闭。
最容易被忽略的是静态单例 + 自动关闭的组合。例如 Spring 中用 @PreDestroy 关闭 ExecutorService，但如果其他 Bean 还在用它，就会出现 RejectedExecutionException。
- 推荐做法：由顶层容器（如 Spring ApplicationContext、Quarkus Runtime）统一管理生命周期
- 手动管理时，确保
shutdown()只在应用退出前调用一次，且所有任务提交路径都明确知道池是否已关闭 - 避免在工具类里提供静态
ExecutorService，除非明确标注“仅供测试”或“内部短时使用”
