嵌套parallelStream使用ManagedBlocker触发RejectedExecutionException问题

1. ForkJoinPool.commonPool的线程数限制 #

ForkJoinPool.commonPool()的默认线程数等于CPU核心数（由Runtime.getRuntime().availableProcessors()决定），且它的核心线程数与最大线程数完全一致，无法扩容。当你在外层用parallelStream占满了commonPool的所有线程后，每个外层线程又启动内层parallelStream：

• 内层并行流的任务需要从commonPool获取线程，但此时池内所有线程都被外层任务占用
• 因为你用了ManagedBlocker调用Thread.sleep，这些外层线程会被标记为阻塞状态，ForkJoinPool会尝试创建新的工作线程来替换阻塞线程，以维持并行处理能力
• 但commonPool的最大线程数已经被占满，无法创建新线程，最终触发RejectedExecutionException: Thread limit exceeded replacing blocked worker异常

2. 自定义ForkJoinPool的扩容特性 #

自定义ForkJoinPool默认的maximumPoolSize是Integer.MAX_VALUE（除非你在构造时手动指定了更小的最大值）：

• 当工作线程因ManagedBlocker进入阻塞状态时，自定义池可以创建新的替换线程，来处理内层并行流的任务
• 不管是内层单独用自定义池，还是内外共用同一个自定义池，只要池的最大线程数足够（默认无上限），就能应对嵌套阻塞的场景，不会触发线程数超限的问题

3. ManagedBlocker的触发逻辑 #

ManagedBlocker的设计目的是让ForkJoinPool感知到线程阻塞，从而临时扩容补充线程，保证并行处理的效率。但这个逻辑依赖于池本身支持扩容——commonPool不支持，所以替换线程的操作失败；自定义池支持，因此可以正常运行。

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