ForkJoinPool线程池挂死问题：提交并行流任务后get()无限阻塞

嘿，这个问题我之前踩过一模一样的坑，典型的ForkJoinPool死锁场景，咱们来好好拆解一下原因和解决办法：

你这段代码的死锁核心在于单线程ForkJoinPool和并行流的冲突使用，具体的死锁链条是这样的：

1. 你创建了一个并行度为1的ForkJoinPool——说白了就是这个池里只有1个工作线程。
2. 你通过pool.submit()提交了一个任务，这个任务由池里的唯一线程执行。
3. 在这个任务内部，你调用了entries.stream().parallel().forEach(...)——这里有个很容易忽略的Java特性：如果当前线程正处于一个ForkJoinPool中，并行流会直接复用这个池来执行自己的子任务，而不是用默认的commonPool。
4. 并行流会把遍历任务拆分成多个子任务，尝试提交到当前的ForkJoinPool中执行，但此时池里的唯一线程正卡在等待这些子任务完成（因为forEach是阻塞操作），根本没有空闲线程来处理子任务。
5. 这就形成了一个死锁闭环：父任务（你submit的那个）在等子任务（并行流拆分的任务）完成，子任务在等池里的空闲线程，而唯一的线程被父任务死死占用着，永远无法释放，最终导致调用get()的线程无限挂起。

这里有几个可行的修复方案，你可以根据自己的业务场景选择：

方案1：直接改用串行流（最简单） #

既然你外层的ForkJoinPool只有1个线程，并行流根本没法真正并行，完全没必要用。直接把并行流换成串行流就行：

ForkJoinPool pool = new ForkJoinPool(1);
List<String> entries = ...;
pool.submit(() -> {
    // 用串行流替代并行流，避免线程池冲突
    entries.stream().forEach(entry -> {
        // I/O操作
        ...
    });
}).get();

方案2：给并行流指定独立的线程池 #

如果你确实需要在任务内部使用并行流，可以让并行流使用单独的线程池（比如默认的commonPool，或者你自己新建的池），避免和外层的单线程池抢资源：

ForkJoinPool pool = new ForkJoinPool(1);
List<String> entries = ...;
pool.submit(() -> {
    // 让并行流使用默认的commonPool执行子任务
    ForkJoinPool.commonPool().invoke(() -> {
        entries.stream().parallel().forEach(entry -> {
            // I/O操作
            ...
        });
    });
}).get();

方案3：调高外层ForkJoinPool的并行度 #

如果你的业务逻辑确实需要外层池支持并行，可以把并行度设置得足够高（至少大于1），这样池里有空闲线程可以处理并行流的子任务：

// 根据你的CPU核心数或业务需求调整并行度，IO密集型任务可以设得更高
ForkJoinPool pool = new ForkJoinPool(4);
List<String> entries = ...;
pool.submit(() -> {
    entries.stream().parallel().forEach(entry -> {
        // I/O操作
        ...
    });
}).get();

• 并行流的线程池选择是个隐形坑：在非ForkJoin线程中调用并行流，会用ForkJoinPool.commonPool()；但在ForkJoin线程中调用，会直接复用当前所在的ForkJoinPool，很多人都会忽略这一点。
• IO密集型任务更适合用ThreadPoolExecutor：ForkJoinPool天生是为CPU密集型任务设计的，IO密集型任务用ThreadPoolExecutor配合合适的队列和线程数设置，能更高效地处理阻塞场景。

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