并行流提交任务至ExecutorService的工作机制及代码疑问

先看你贴的代码，这里存在双重线程池滥用的问题，下面逐个解答你的疑问：

问题1：parallel()的拆分逻辑与线程数控制 #

Java并行流默认使用ForkJoinPool.commonPool()，它的默认并行度（即同时工作的线程数）是CPU核心数（别被旧说法误导，不是核心数-1）。

• 流的拆分规则由数据源的Spliterator实现决定：比如ArrayList的Spliterator支持均匀拆分，会尽量把元素均分给各个线程；但像LinkedList这类非随机访问的集合，拆分效率低，很难做到均分。
• 拆分和并行度是可以控制的：
  • 通过系统属性java.util.concurrent.ForkJoinPool.common.parallelism调整commonPool的并行度；
  • 用自定义ForkJoinPool包裹并行流的执行，完全接管线程池；
  • 自定义Spliterator来控制元素拆分规则（一般业务场景很少用到）。

问题2：ExecutorService的必要性分析 #

这段代码同时用并行流和ExecutorService完全是多此一举：

• 并行流本身已经通过commonPool的线程来完成列表的遍历、过滤操作，现在你又把每个元素对应的任务提交到另一个8线程的池，相当于让并行流的线程只干“提交任务”的轻量工作，真正的业务逻辑交给FixedThreadPool处理，属于重复的线程调度。
• 正确做法二选一即可：要么只用并行流处理（把Myclass的逻辑直接放到forEach里），要么先过滤列表，再把所有过滤后的元素任务一次性提交给FixedThreadPool，不需要并行流参与。

问题3：线程数从8降至3的原因 #

你看到的应该是活跃线程数的变化，而非线程池的总线程数。FixedThreadPool的核心线程数是8，这些线程创建后不会被销毁，只是在空闲时处于等待状态。当待处理任务只剩3个时，线程池只会唤醒3个线程处理任务，其余5个线程处于空闲，所以你观察到的活跃线程数会降到3，这是线程池的正常调度行为。

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