高频调用的静态方法中使用ExecutorService的最优方案探讨

我有一个受时间限制的方法，在7×24小时运行的并发环境服务器上被频繁调用。正在考虑以下两种优化方案，想从性能、GC（垃圾回收）及正确性角度判断哪种最优：

方案1：每次调用创建并关闭ExecutorService #

public static boolean doSomeWork(@Nonnull String input) {
    ExecutorService executorService = Executors.newSingleThreadExecutor();
    Future<Boolean> future = executorService.submit(() -> checkSmth(input));
    try {
        return future.get(Constants.TIMEOUT_MILLIS, TimeUnit.MILLISECONDS);
    } catch (InterruptedException | ExecutionException | TimeoutException e) {
        future.cancel(true);
        return false;
    } finally {
        shutdownExecutorGracefully(executorService);
    }
}

private static void shutdownExecutorGracefully(ExecutorService executorService) {
    executorService.shutdown();
    try {
        if (!executorService.awaitTermination(Constants.EXECUTOR_SERVICE_SHUTDOWN_TIMEOUT_MILLIS, TimeUnit.MILLISECONDS)) {
            executorService.shutdownNow();
        }
    } catch (InterruptedException e) {
        executorService.shutdownNow();
    }
}

方案2：使用静态ExecutorService且不调用shutdown #

private static final ExecutorService executorService = Executors.newSingleThreadExecutor();

public static boolean doSomeWork(@Nonnull String input) {
    Future<Boolean> future = executorService.submit(() -> checkSmth(input));
    try {
        return future.get(Constants.TIMEOUT_MILLIS, TimeUnit.MILLISECONDS);
    } catch (InterruptedException | ExecutionException | TimeoutException e) {
        future.cancel(true);
        return false;
    }
}

各维度对比分析 #

1. 性能角度 #

• 方案1：每次调用都要创建ExecutorService（底层包含线程、任务队列等资源），调用结束后还要执行优雅关闭的一系列操作。频繁调用下，线程的创建、销毁以及线程池的关闭流程会带来巨大的性能开销，直接拉低方法的响应速度。
• 方案2：静态ExecutorService是单例实例，仅在类加载时创建一次，后续所有调用复用同一个线程池。完全避免了重复创建销毁资源的开销，在高频调用场景下性能优势极其显著。

2. GC（垃圾回收）角度 #

• 方案1：每次调用都会生成新的ExecutorService、线程对象、队列实例等短期对象，这些对象在方法结束后都会成为垃圾。高频调用会快速堆积大量垃圾，触发频繁的Minor GC，严重时甚至引发Major GC，增加GC停顿时间，影响服务器的稳定性和吞吐量。
• 方案2：仅在类加载阶段创建一次线程池及其内部资源，后续无额外垃圾对象产生，几乎不会给GC带来压力，对服务器内存稳定性更友好。

3. 正确性角度 #

• 方案1：每次调用独立创建线程池，任务之间完全隔离，不会出现排队等待的情况。优雅关闭的逻辑是正确的，即使awaitTermination超时，也会强制关闭线程池，不会出现资源泄漏。但频繁创建销毁线程池本身不会导致逻辑错误，只是性能太差。
• 方案2：单线程池会让所有任务排队执行，同一时间只能处理一个任务。如果checkSmth执行速度快，调用频率在单线程处理能力范围内，那么正确性完全没问题；但如果调用频率远高于单线程处理速度，任务队列会持续积压，后续任务还没开始执行就会触发超时返回false，这不符合业务预期。另外，静态线程池永不shutdown在7×24小时运行的服务器上是合理的，只要checkSmth逻辑正确，不会出现线程泄漏问题，线程会在任务完成后回到池内等待下一次任务。

最优方案结论 #

如果checkSmth的执行效率足够高，方法调用频率在单线程的处理能力范围内，方案2是最优选择，它在性能和GC上的优势非常明显，正确性也能得到保障。

如果方法调用频率极高，单线程无法及时处理所有任务导致大量超时，建议调整为固定大小的线程池（比如Executors.newFixedThreadPool(n)），根据业务压力设置合适的线程数，既避免方案1的性能开销，又能应对高并发的任务排队需求。

内容的提问来源于stack exchange，提问作者Stranger95