在Java并发工具链中，并行流与ExecutorService分别代表了两种不同的并发任务执行模型。前者将并行计算隐藏在Stream API背后，后者则把线程池的每个细节都暴露给开发者。要真正用好它们，必须从线程池模型、任务拆分策略以及阻塞行为入手，而不是仅凭直觉选择。本文通过源码层面的分析和可运行的示例，对这两套机制做一次直接对比。

并行流依赖的公共ForkJoinPool：默认行为与隐患

Java 8引入的并行流默认使用ForkJoinPool.commonPool()作为执行引擎。这个公共池的线程数量由Runtime.getRuntime().availableProcessors()决定，通常等于CPU核心数减一。在没有显式配置的情况下，所有并行流任务、CompletableFuture的默认异步回调以及Arrays.parallelSort等都共享同一个commonPool。这种设计降低了入门门槛，但也埋下了资源争用的隐患。如果JVM中同时运行多个并行流任务，它们会争抢有限的线程，导致整体吞吐量下降。

并行流内部使用递归任务拆分机制，将一个大数据集不断对半切分，直到子任务足够小，然后由工作窃取线程并行处理。这个过程对于纯CPU计算非常高效，因为线程切换开销较小，且工作窃取能较好地平衡负载。但如果处理逻辑中夹杂了阻塞式I/O，比如数据库查询或HTTP调用，线程会被阻塞，而且公共池并不会为阻塞任务创建额外线程。结果就是公共线程池被占满，其他依赖commonPool的异步任务全部饿死，甚至连并行流自身都陷入停顿。这是实际项目中最常见也最危险的一种误用。

// 打印公共ForkJoinPool的并行度
System.out.println("CPU核心数: " + Runtime.getRuntime().availableProcessors());
System.out.println("公共池并行度: " + ForkJoinPool.commonPool().getParallelism());
List<Integer> numbers = IntStream.rangeClosed(1, 100_000).boxed().collect(Collectors.toList());
long sum = numbers.parallelStream()
        .mapToLong(Integer::longValue)
        .sum();
System.out.println("并行流计算结果: " + sum);

上面的代码展示了并行流最典型的用法。表面上看它没有创建任何线程池，但底层确实借用了公共ForkJoinPool。如果此时有其他异步任务也在使用commonPool，就可能出现线程竞争。更严重的是，公共池的线程数无法通过并行流API直接调整，只能通过系统属性java.util.concurrent.ForkJoinPool.common.parallelism在JVM启动时指定，一旦应用运行起来就难以改变。这种硬编码式的配置对于需要动态调优的系统来说极不友好。

ExecutorService的精细线程池控制：参数、队列与拒绝策略

与并行流不同，ExecutorService允许开发者精确配置核心线程数、最大线程数、存活时间、工作队列类型以及拒绝策略。通过ThreadPoolExecutor的构造函数，可以创建适用于不同场景的线程池。例如，对于I/O密集任务，通常把线程数设置为核心数的两倍甚至更高，并使用有界队列配合CallerRunsPolicy拒绝策略，防止任务堆积导致内存溢出。

ExecutorService的优势在于任务提交和结果获取是显式的，通过Future可以单独处理每个任务的异常，也可以调用invokeAll批量等待。其线程池扩容机制能够在线程数未达到最大值时，为突发流量创建新线程，只要队列已满。这种弹性是并行流公共池所不具备的。不过配置错误也会带来问题，比如将无界队列与较小最大线程数搭配，会导致任务长时间排队，响应延迟升高；使用默认的AbortPolicy又可能因为队列耗尽直接抛出RejectedExecutionException，打乱业务流程。

int corePoolSize = 4;
int maxPoolSize = 8;
long keepAliveTime = 60L;
BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<Runnable>(200);
ThreadFactory threadFactory = r -> {
    Thread t = new Thread(r, "worker-thread");
    t.setDaemon(false);
    return t;
};
RejectedExecutionHandler handler = new ThreadPoolExecutor.CallerRunsPolicy();
ExecutorService executor = new ThreadPoolExecutor(
        corePoolSize,
        maxPoolSize,
        keepAliveTime,
        TimeUnit.SECONDS,
        workQueue,
        threadFactory,
        handler
);
List<Future<Integer>> futures = new ArrayList<>();
for (int i = 0; i < 100; i++) {
    final int taskId = i;
    futures.add(executor.submit(() -> {
        TimeUnit.MILLISECONDS.sleep(50);
        return taskId * taskId;
    }));
}
for (Future<Integer> future : futures) {
    future.get();
}
executor.shutdown();

通过这段代码可以看到，ExecutorService把线程池的每个参数都暴露出来，程序员可以根据业务需要灵活调整。比如核心线程数可以设置得与CPU核心数一致，最大线程数则根据峰值流量估算，队列容量用来吸收突发请求。当线程数达到最大且队列满时，CallerRunsPolicy会让提交任务的线程直接执行该任务，从而形成天然的背压机制，避免系统被击垮。这种控制粒度是并行流无法提供的。

混用场景与自定义ForkJoinPool的隔离技巧

一个常见的疑问是：能否让并行流使用自定义线程池？并行流API本身没有提供直接指定ExecutorService的重载方法，但可以通过把并行流操作包在自定义ForkJoinPool的submit调用中实现。ForkJoinPool实现了ExecutorService，当并行流任务在自定义池中执行时，其内部的ForkJoinTask会使用该池的工作线程，而不是commonPool。这种方法常用于在Web应用中隔离不同的并行计算负载。

ForkJoinPool customPool = new ForkJoinPool(4);
try {
    Integer result = customPool.submit(() ->
        IntStream.range(1, 100_000)
                 .parallel()
                 .map(x -> x * x)
                 .sum()
    ).get();
    System.out.println("自定义池计算结果: " + result);
} finally {
    customPool.shutdown();
}

这种技巧确实能起到隔离作用，但也要注意：阻塞式I/O并不适合用并行流，即便放在自定义ForkJoinPool中，仍然可能耗尽池内线程，而且ForkJoinPool设计初衷是处理可拆分的CPU密集型任务，对阻塞操作没有补偿机制。如果任务中必须执行阻塞I/O，应果断选择ExecutorService或CompletableFuture的异步组合，而不是硬套并行流。

另外，并行流中的异常处理比较隐蔽。由于任务在多个线程中执行，异常会被包装成ExecutionException或直接抛出到调用线程。如果某个子任务抛出未捕获异常，整个流的操作会中止，但其他线程可能还在执行，造成部分计算结果丢失。ExecutorService可以通过Future.get捕获单任务异常，但并行流更适合无状态、无副作用的纯函数运算。

性能对比与选型决策

在CPU密集型的批量计算中，并行流和ExecutorService都能利用多核优势，但并行流往往能用更少的代码获得接近甚至超过ExecutorService的性能，因为它的任务拆分由框架自动完成。以一个包含500万个整数的求和操作为例，串行流耗时约80毫秒，并行流在8核机器上可以降到30毫秒左右，与手动划分任务提交给ExecutorService的结果接近。但并行流的启动会消耗部分时间用于公共池的初始化和任务拆分，数据量越小，并行收益越不明显，甚至可能比串行更慢。

最终选择并没有绝对标准。如果任务是纯计算、无阻塞、且需要快速实现，并行流是首选，但务必确认JVM中不会同时弹出多个公共池依赖。对于需要精确控制并发度、任务队列长度、线程命名的生产系统，ExecutorService更加可靠。混合使用两者时，要避免在公共池中执行阻塞代码，必要时通过自定义ForkJoinPool做隔离。理解了这些底层机制，才能在项目中避开并发陷阱，充分发挥多核性能。