关键区别在于submit()返回Future支持结果获取与异常捕获，execute()无返回且未捕获异常会静默丢失；newFixedThreadPool因无界队列易OOM，应显式构造有界队列线程池；安全关闭需shutdown()+awaitTermination()+必要时shutdownNow()；corePoolSize与maximumPoolSize需依CPU/IO密集型及压测数据合理设定。
ExecutorService.submit() 和 execute() 的区别在哪
关键不在“能不能提交任务”，而在“要不要返回结果”和“异常处理方式不同”。submit() 返回 Future，支持获取结果、主动取消、判断完成状态；execute() 无返回值，且若任务抛出未捕获异常，会静默丢失（除非配置了 ThreadFactory 设置 UncaughtExceptionHandler）。
常见错误：用 execute() 提交需要结果的任务，后续无法获取返回值；或误以为 submit() 会阻塞等待执行——它只是立即返回 Future，真正阻塞在 get() 调用时。
- 需要异步结果或超时控制 → 用
submit() - 纯“发完就不管”的后台任务（如日志上报、指标打点）→
execute()更轻量 - 所有任务都应考虑异常兜底：重写
ThreadFactory或统一 try-catch 包裹Runnable/Callable
为什么 newFixedThreadPool() 不推荐用于生产环境
核心问题是其内部使用的 LinkedBlockingQueue 默认无界（容量为 Integer.MAX_VALUE），一旦任务提交速率持续高于消费速率，队列无限增长，最终触发 OutOfMemoryError。
这不是线程池“不够用”，而是队列失控。很多线上 OOM 案例都源于此，尤其在下游响应变慢、重试逻辑缺失的场景下。
立即学习“Java免费学习笔记（深入）”；
- 替代方案：用
new ThreadPoolExecutor(...)显式构造，指定有界队列（如ArrayBlockingQueue(1024)） - 拒绝策略必须显式设置：
AbortPolicy（抛异常）、CallerRunsPolicy（由提交线程自己执行）等，不能依赖默认 -
Executors.newCachedThreadPool()同样危险：最大线程数为Integer.MAX_VALUE，突发流量可能创建海量线程，压垮系统
如何安全地关闭 ExecutorService
调用 shutdown() 只是“不再接收新任务”，已提交任务仍会执行；而 shutdownNow() 尝试中断所有正在运行的线程，但不保证成功（比如线程没响应中断）。
真正的安全关闭 = 等待 + 中断 + 超时兜底。漏掉任意一环，都可能导致 JVM 无法退出或资源泄漏。
- 先
shutdown()，再awaitTermination(timeout, unit)等待自然结束 - 超时后若仍有活跃任务，可选
shutdownNow()强制终止（注意：仅对响应中断的逻辑有效） - 务必在
finally块或try-with-resources（配合自定义AutoCloseable封装）中执行关闭逻辑 - 不要在 shutdown 后继续 submit/execute —— 会抛
RejectedExecutionException
ThreadPoolExecutor 的 corePoolSize 和 maximumPoolSize 怎么设
没有万能公式。设错的后果很直接：要么资源闲置（core 太大），要么频繁扩容缩容（core 太小），或者任务排队过长（max 不够）。
真实系统里，这两个值要结合 CPU 密集型/IO 密集型、平均响应时间、QPS、下游稳定性综合判断，而不是拍脑袋填数字。
- CPU 密集型（如图像处理）：corePoolSize ≈ CPU 核数，maximumPoolSize 可略高（+1~2），避免线程上下文切换开销
- IO 密集型（如 HTTP 调用）：corePoolSize 可设为
2 × CPU 核数或更高，因线程常阻塞；maximumPoolSize 需预留缓冲，防止单点抖动拖垮全局 - 永远保留 buffer：maximumPoolSize > corePoolSize，否则
keepAliveTime失效，线程无法回收 - 动态调整？JDK 自带线程池不支持运行时修改 core/max，如需弹性，得自己封装或用第三方库（如 Apache Commons Pool）
线程池不是“越大越好”，也不是“越小越省”。它的参数组合本质上是在吞吐、延迟、资源占用之间做取舍，而这个取舍点，往往藏在压测数据和线上慢请求 trace 里，不在文档里。
