在Ja va并发编程中，直接使用 new Thread() 开启任务，效率低下且难以管理。

这就像每次出行都现造一辆车，会消耗大量系统资源。

Executor框架的核心价值，在于将“执行任务”与“管理线程”解耦。它提供了一套可控的并发资源调度方案。

为什么直接 new Thread() 是错的起点

每次 new Thread() 启动任务，都会：

• 创建新线程
• 分配栈内存
• 触发上下文切换

这导致资源开销大，且无法复用或统一控制。

Executor框架让开发者只关注 Runnable 或 Callable 的业务逻辑，而将线程生命周期管理交给框架。

如何选对 ExecutorService 实现类

Ja va提供的静态工厂方法看似方便，但不同场景下行为差异极大。

常用工厂方法及其风险

• Executors.newFixedThreadPool(n)：适合负载稳定、任务耗时相近的场景。但其内部 LinkedBlockingQueue 默认无界，任务积压可能导致 OOM。
• Executors.newCachedThreadPool()：适合大量短生命周期任务。但空闲线程60秒后才回收，突发流量可能创建过多线程，压垮系统。
• Executors.newSingleThreadExecutor()：保证顺序执行。但存在单点故障风险，且无法扩展。

生产环境推荐做法

强烈建议使用 new ThreadPoolExecutor(...) 手动构造线程池。

这样可以精确控制：

• 核心线程数
• 最大线程数
• 队列类型（如使用 ArrayBlockingQueue 限制容量）
• 拒绝策略（如 AbortPolicy 或自定义策略）

submit() 和 execute() 到底该用哪个

关键区别在于“是否需要结果”和“异常处理方式”。

execute(Runnable)

• 只接受 Runnable 任务。
• 无返回值。
• 若任务抛出未捕获异常，异常会直接打印到 stderr，且线程可能静默终止。

submit(Runnable) 或 submit(Callable)

• 返回 Future 对象。
• 可调用 future.get() 获取结果或捕获异常。
• 即使任务抛异常，也会被封装在 ExecutionException 中，不会丢失。

重要提示：如果任务有业务级失败需要重试或告警，必须使用 submit()，并配合显式的 future.get() 或 future.isDone() 进行检查。

关闭线程池时 shutdown() 和 shutdownNow() 的陷阱

不正确的关闭会导致任务丢失、线程泄漏或JVM无法退出。

shutdown()：平滑关闭

• 不再接收新任务。
• 会等待已提交任务（包括队列中等待的）执行完毕。
• 需配合 awaitTermination() 等待完成，否则主线程可能提前退出。

shutdownNow()：强制关闭

• 尝试中断所有正在运行的线程。
• 清空队列，并返回未执行的任务列表。
• 但中断只是“建议”，任务本身必须响应 Thread.interrupted() 或检查 isInterrupted() 才会真正停止。

常见错误与安全关闭流程

常见错误是只调用 shutdown() 就不管了，或者在 finally 块里没有调用 awaitTermination() 进行等待。

真正安全的关闭流程通常分为三步：

1. 先调用 shutdown()。
2. 接着使用 awaitTermination(30, TimeUnit.SECONDS) 等待。
3. 如果超时，最后再调用 shutdownNow() 进行强制清理。

《夸克》非常好用的免费AI浏览器

下载APP查看