Java并发编程：ExecutorService使用全解析

一分耕耘，一分收获！既然打开了这篇文章《Java并发编程：ExecutorService使用详解》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

Future.get()卡住的根本原因是任务未结束或被I/O、锁等阻塞；其为同步阻塞调用，不主动中断任务；cancel(true)仅靠任务响应中断信号才生效，否则无效。

ExecutorService.submit() 返回的 Future 为什么有时 get() 会卡住

根本原因是任务本身没结束，或者被阻塞在 I/O、锁、无限循环里，Future.get() 是同步阻塞调用，它不会主动中断正在运行的任务。

• 默认情况下，ExecutorService 不会因 Future.cancel(true) 就强制终止线程——JVM 不支持真正“杀掉”线程，只能靠任务自己响应 Thread.interrupted()
• 如果任务中用了 Object.wait()、Thread.sleep() 或可中断的 NIO 操作，cancel(true) 才会生效并抛出 InterruptedException
• 常见陷阱：提交了一个无超时的 get()，而任务因数据库连接超时未设 timeout，结果主线程永久挂起

稳妥做法是始终带超时：

try {
    result = future.get(3, TimeUnit.SECONDS);
} catch (TimeoutException e) {
    future.cancel(true); // 尝试中断
    throw new RuntimeException("Task timed out", e);
}

shutdown() 和 shutdownNow() 的实际行为差异

shutdown() 是温柔退场：拒绝新任务，但允许已提交的（包括队列里排队的）任务继续执行完；shutdownNow() 是硬中断：尝试中断所有正在执行的任务，并清空任务队列，返回尚未执行的任务列表。

• shutdownNow() 并不保证任务立刻停止——它只是对每个工作线程调用 Thread.interrupt()，能否响应取决于任务代码是否检查中断状态
• 如果任务正持有 synchronized 锁或在 native 方法中，中断信号会被忽略，线程仍会继续执行直到自然退出
• 生产环境建议优先用 shutdown() + awaitTermination() 组合，留出合理等待窗口

典型安全关闭流程：

executor.shutdown();
try {
    if (!executor.awaitTermination(10, TimeUnit.SECONDS)) {
        executor.shutdownNow();
        if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
            System.err.println("Pool did not terminate gracefully");
        }
    }
} catch (InterruptedException e) {
    executor.shutdownNow();
    Thread.currentThread().interrupt();
}

FixedThreadPool 为什么不适合处理大量短时 IO 任务

因为它的核心线程数固定且永不回收，一旦任务涉及网络/磁盘 I/O，线程会长时间阻塞在 read()、accept() 等系统调用上，导致线程资源被无效占用，吞吐量骤降。

• FixedThreadPool 底层用的是 LinkedBlockingQueue（无界队列），任务持续涌入时，队列无限增长，可能引发 OOM
• 替代方案应选 newCachedThreadPool()（适合大量短生命周期任务）或更可控的 newThreadPoolExecutor() 配合 SynchronousQueue 和自定义拒绝策略
• 现代推荐：直接用 ForkJoinPool.commonPool() 处理 CPU 密集型任务；IO 密集型则交给 Netty、Vert.x 等异步框架，而非裸 ExecutorService

使用 CompletionService 统一收集异步结果的必要场景

当多个异步任务耗时差异大，又需要“谁先完成就先处理谁的结果”，而不是按提交顺序 get()，就必须用 CompletionService。否则你得维护一堆 Future，轮询或按序阻塞，效率低且易出错。

• CompletionService 内部封装了阻塞队列（如 LinkedBlockingQueue），任务完成即入队，take() 总能拿到最先结束的那个
• 注意：它不改变任务执行逻辑，只是结果获取方式更灵活；底层仍依赖传入的 ExecutorService
• 别误以为它能“自动重试失败任务”——异常仍需在 future.get() 里显式捕获

简单用法示例：

ExecutorService executor = Executors.newFixedThreadPool(4);
CompletionService<string> cs = new ExecutorCompletionService(executor);
<p>for (int i = 0; i < 5; i++) {
cs.submit(() -> {
Thread.sleep(1000 * i); // 模拟不同耗时
return "result-" + i;
});
}</p><p>for (int i = 0; i < 5; i++) {
try {
String result = cs.take().get(); // 按完成顺序获取
System.out.println(result);
} catch (ExecutionException e) {
e.printStackTrace();
}
}</p></string>

线程池不是万能胶，用错类型或忽略生命周期管理，比不用还危险。尤其要注意中断语义的脆弱性——它只是一次通知，不是指令。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。