submit() 返回Future可获取结果、判断状态、主动取消；execute()为void方法，不捕获异常，任务抛未检查异常会导致线程静默终止。
ExecutorService.submit() 和 execute() 的区别必须分清
submit() 返回 Future，能取结果、判断状态、主动取消；execute() 是 void 方法，只负责提交，连异常都捕获不到——一旦任务抛出未检查异常，线程会静默终止，ThreadPoolExecutor 甚至不会重开线程（除非配置了 ThreadFactory 或自定义 RejectedExecutionHandler）。
常见错误：用 execute() 提交需要返回值的任务，然后傻等结果；或误以为 execute() 会传播异常到主线程。
- 要取结果、控制生命周期 → 用
submit(Runnable)或submit(Callable) - 只发通知、不关心成败 →
execute(Runnable)更轻量 - 所有提交都建议包裹 try-catch，尤其
submit(Callable)的get()可能抛ExecutionException和InterruptedException
shutdown() 和 shutdownNow() 不是“关机按钮”，而是状态切换指令
shutdown() 设置线程池为 SHUTDOWN 状态，拒绝新任务，但继续执行已提交的队列任务；shutdownNow() 设置为 STOP 状态，尝试中断所有正在运行的线程，并清空工作队列，返回未执行的 Runnable 列表。
关键点：中断 ≠ 终止。如果任务没响应 Thread.interrupted() 或没在可中断点（如 sleep、wait、join）检查中断状态，shutdownNow() 对它完全无效。
立即学习“Java免费学习笔记（深入）”；
- 优雅停机必须配合任务自身支持中断：在循环中加
if (Thread.currentThread().isInterrupted()) break; -
awaitTermination(long, TimeUnit)必须跟在shutdown()后调用，否则永远返回 false - 别在 finally 块里只写
shutdownNow()—— 它不保证等待完成，应搭配awaitTermination()循环重试
FixedThreadPool 和 CachedThreadPool 的坑比想象中多
Executors.newFixedThreadPool(n) 底层用的是无界 LinkedBlockingQueue，任务持续涌入时内存会无限增长；Executors.newCachedThreadPool() 使用 SynchronousQueue + 60 秒空闲回收，看似灵活，但突发大量短任务可能瞬间创建成百上千线程，打爆系统资源。
真实项目几乎不该直接用这两个工厂方法。
- 替代
newFixedThreadPool：用new ThreadPoolExecutor(core, max, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(queueSize))，显式控队列大小 - 替代
newCachedThreadPool：设合理corePoolSize，用keepAliveTime > 0，并指定有界队列 - 永远不要依赖
Executors创建的线程池做生产级调度 —— 它们缺失拒绝策略、线程命名、异常处理钩子等关键能力
线程池拒绝策略不是摆设，得选对再定制
默认的 AbortPolicy 直接抛 RejectedExecutionException；CallerRunsPolicy 让提交线程自己执行任务，可能拖慢上游；DiscardPolicy 和 DiscardOldestPolicy 都是静默丢弃，毫无可观测性。
真正健壮的服务至少要记录被拒任务的类型、参数摘要和堆栈（哪怕只是 warn 日志），否则压测时崩了都不知道瓶颈在哪。
- 自定义策略继承
RejectedExecutionHandler，在rejectedExecution()里打日志 + 上报指标（如 Prometheus counter） - 若任务可降级，这里可以触发 fallback 逻辑（如写入本地队列、转异步消息）
- 别忘了：拒绝只发生在
workQueue.offer()失败后，所以队列容量和拒绝策略必须协同设计
线程池不是“启动就完事”的组件，它的核心难点从来不在创建，而在与业务生命周期对齐、对异常流的兜底、以及对资源边界的诚实评估。稍不注意，submit() 调用点就成了系统隐性单点。
