ExecutorService 是统一调度任务的接口，封装线程复用、队列缓冲、拒绝策略与优雅关闭能力；相比 new Thread() 可避免资源失控与 OOM 风险。
ExecutorService 是什么，为什么不用 new Thread()
它不是线程池的“实现类”，而是统一调度任务的接口。直接 new Thread() 启动线程会导致资源失控：线程创建销毁开销大、无复用、无统一生命周期管理、OOM 风险高。而 ExecutorService 封装了线程复用、队列缓冲、拒绝策略、优雅关闭等关键能力。
实际开发中，几乎不手动实现 ExecutorService，而是通过 Executors 工具类获取标准实现：
ExecutorService pool = Executors.newFixedThreadPool(4); ExecutorService pool = Executors.newCachedThreadPool(); ExecutorService pool = Executors.newSingleThreadExecutor();
但要注意：Executors 创建的几种默认池在生产环境有隐患——比如 newCachedThreadPool() 使用无界 SynchronousQueue，任务爆发时会无限创建线程；newFixedThreadPool() 的任务队列是无界 LinkedBlockingQueue，可能撑爆堆内存。所以更推荐显式构造 ThreadPoolExecutor。
如何安全地创建和关闭 ThreadPoolExecutor
显式构造能控制核心参数：核心线程数、最大线程数、空闲线程存活时间、任务队列、拒绝策略。这是避免线上事故的关键一步。
立即学习“Java免费学习笔记（深入）”；
常见错误包括：用 shutdownNow() 强制中断正在执行的任务（可能破坏数据一致性）、忘记调用 awaitTermination() 导致 JVM 提前退出、或在 finally 块外关闭导致资源泄漏。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
shutdown()：停止接收新任务，已提交任务继续执行 -
shutdownNow()：尝试中断所有运行中线程，并返回未执行的任务列表 - 必须配合
awaitTermination(long, TimeUnit)等待终止完成，超时后应做日志或兜底处理
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, 4,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100),
new ThreadPoolExecutor.CallerRunsPolicy()
);
// ... 提交任务
executor.shutdown();
try {
if (!executor.awaitTermination(10, TimeUnit.SECONDS)) {
executor.shutdownNow();
}
} catch (InterruptedException e) {
executor.shutdownNow();
Thread.currentThread().interrupt();
}
submit() 和 execute() 的区别在哪
两者都用于提交任务，但语义和用途完全不同：
-
execute(Runnable)：仅执行，无返回值，不支持异常捕获，适用于“发完就不管”的场景 -
submit(Runnable)或submit(Callable)：返回Future，可主动获取结果、判断是否完成、取消任务、捕获执行异常
典型陷阱：用 submit(Runnable) 后不调用 get()，导致任务内抛出的异常被吞掉（FutureTask 内部只在 get() 时重抛）；或者在循环中反复 submit().get()，造成串行阻塞，失去并发意义。
Future<String> future = executor.submit(() -> {
// 可能抛异常
return "done";
});
// 必须 get() 才能看到异常
try {
String result = future.get(); // 阻塞直到完成
} catch (ExecutionException e) {
Throwable cause = e.getCause(); // 真实异常在这里
}
CompletableFuture 与 ExecutorService 怎么配合用
CompletableFuture 默认使用 ForkJoinPool.commonPool()，但 IO 密集型任务（如 HTTP 调用、DB 查询）不该挤占这个 CPU 密集型线程池。正确做法是显式传入自定义 ExecutorService。
容易忽略的点：异步链式调用中，每个 thenApplyAsync、thenComposeAsync 都可以指定不同线程池；若不指定，会继续用上一个阶段的线程池，可能导致 IO 任务卡住 CPU 密集型计算。
- IO 类型任务：用专为 IO 优化的线程池（如核心数 × 2～4，带较大队列）
- CPU 密集型任务：线程数 ≈ CPU 核心数，避免上下文切换开销
- 不要混用：避免把 DB 查询和图像压缩放在同一个池里
ExecutorService ioPool = Executors.newFixedThreadPool(8);
CompletableFuture.supplyAsync(() -> fetchFromDatabase(), ioPool)
.thenApplyAsync(data -> processInMemory(data),
ForkJoinPool.commonPool());
线程池命名、监控、拒绝策略日志这些细节，在压测和上线后才真正暴露价值。别等告警响了才想起没给 ThreadFactory 设置名称。
