Java并发编程中的ExecutorService与异步任务

Future.get() 不阻塞的根本原因是任务未启动或线程池已拒绝任务；shutdown后submit直接抛RejectedExecutionException，不返回Future。

ExecutorService.submit() 返回的 Future 为什么可能不触发 get() 阻塞？

根本原因在于任务本身是否真正启动或是否被线程池接受。如果

ExecutorService 已 shutdown() 或 shutdownNow()，后续 submit() 会直接抛出 RejectedExecutionException，根本不会返回 Future；而即使返回了 Future，若任务因异常在构造阶段失败（如 Callable 的 call() 方法抛出未捕获异常），get() 仍会阻塞——但最终抛出 ExecutionException 包裹原始异常。

实操建议：

• 始终在 submit() 前确认线程池状态：if (!executor.isShutdown() && !executor.isTerminated()) { ... }
• 对 Future.get() 加超时控制，避免无限等待：future.get(3, TimeUnit.SECONDS)
• 捕获 ExecutionException、TimeoutException、CancellationException 三类异常，不可只 catch Exception

用 ExecutorService 执行 Runnable 和 Callable 有什么关键区别？

核心差异在返回值与异常传播机制。Runnable 无返回值、run() 方法不能抛受检异常；Callable 有泛型返回值、call() 可抛任意异常，且该异常会被封装进 Future.get() 抛出的 ExecutionException 中。

实操建议：

• 需要结果或需区分成功/失败场景，必须用 Callable，别试图在 Runnable 里写全局变量“取结果”
• submit(Runnable task) 实际返回的是 Future>，其 get() 永远返回 null，不是“没结果”，而是设计如此
• 若用 Lambda 写 Callable，注意类型推导：executor.submit(() -> { doWork(); return "done"; }) 的返回类型由 Lambda 主体决定

ThreadPoolExecutor 的 corePoolSize 和 maximumPoolSize 设多少才合理？

没有通用值，取决于任务 I/O 特性与 CPU 密集度。设错会导致线程饥饿或资源浪费：core 太小，短突发任务排队；max 太大，大量空闲线程争抢 CPU 上下文。

实操建议：

• 纯 CPU 密集任务：参考 Runtime.getRuntime().availableProcessors()，core = max = N 或 N+1
• 混合型（如 Web 请求含 DB 查询）：core 可设为 N～2N，max 根据最大并发请求数预估，但务必配 LinkedBlockingQueue（无界）或带容量的 ArrayBlockingQueue，避免拒绝策略误杀
• 永远不要用 Executors.newCachedThreadPool() 生产环境——它的 maximumPoolSize 是 Integer.MAX_VALUE，OOM 风险极高

如何安全关闭 ExecutorService 并等待所有异步任务完成？

直接调用 shutdown() 不等于“立刻停”，它只是停止接收新任务；已提交任务继续执行。必须配合 awaitTermination() 等待结束，否则 JVM 可能提前退出，导致任务被强行中断。

实操建议：

• 标准关闭流程必须是三步：shutdown() → awaitTermination() → 若超时则 shutdownNow()
• awaitTermination() 返回 false 表示超时，此时再调 shutdownNow() 会尝试中断正在运行的任务（依赖任务自身响应 Thread.interrupted()）
• 务必在 finally 块中执行关闭逻辑，防止异常跳过：

try {
    executor.submit(() -> doWork());
} finally {
    executor.shutdown();
    try {
        if (!executor.awaitTermination(10, TimeUnit.SECONDS)) {
            executor.shutdownNow();
        }
    } catch (InterruptedException e) {
        executor.shutdownNow();
        Thread.currentThread().interrupt();
    }
}

最易被忽略的一点：任务内部若用了不可中断的阻塞操作（如 InputStream.read()、某些 JNI 调用），shutdownNow() 无法真正终止它，只能靠超时或外部信号。这种任务必须自行实现可取消逻辑。