java并行处理list_java – 为什么Files.list()并行流执行比使用Collection.parallelStream()慢得多？...

问题是当前实现Stream API以及目前对于未知大小源的IteratorSpliterator的实现，将这些源分解成并行任务。你很幸运有超过1024个文件，否则根本就没有并行化的好处。 Current Stream API实现考虑了从Spliterator返回的estimateSize()值。未知大小的IteratorSpliterator在拆分之前返回Long.MAX_VALUE，其后缀总是返回Long.MAX_VALUE。其分裂策略如下：

>定义当前批量大小。当前公式是从1024个元素开始，并且算术增加(2048,3072,4096,5120等等)，直到达到MAX_BATCH大小(这是33554432个元素)。

>将输入元素(在您的路径中)消耗到数组中，直到达到批量大小或输入已用尽。

>返回ArraySpliterator，将创建的数组作为前缀进行迭代，将其作为后缀。

假设你有7000个文件。 Stream API要求估计大小，IteratorSpliterator返回Long.MAX_VALUE。好的，Stream API要求IteratorSpliterator进行拆分，它从基础的DirectoryStream中收集1024个元素到数组，并分解为ArraySpliterator(估计大小为1024)和本身(估计的大小仍然是Long.MAX_VALUE)。由于Long.MAX_VALUE远远超过1024，Stream API决定继续拆分较大的部分，甚至不用拆分较小的部分。所以整体分裂树如下所示：

IteratorSpliterator (est. MAX_VALUE elements)

| |

ArraySpliterator (est. 1024 elements) IteratorSpliterator (est. MAX_VALUE elements)

| |

/---------------/ |

| |

ArraySpliterator (est. 2048 elements) IteratorSpliterator (est. MAX_VALUE elements)

| |

/---------------/ |

| |

ArraySpliterator (est. 3072 elements) IteratorSpliterator (est. MAX_VALUE elements)

| |

/---------------/ |

| |

ArraySpliterator (est. 856 elements) IteratorSpliterator (est. MAX_VALUE elements)

|

(split returns null: refuses to split anymore)

所以之后你有五个并行的任务被执行：实际上包含1024,2048,3072,856和0元素。请注意，即使最后一个块有0个元素，它仍然报告它估计有Long.MAX_VALUE个元素，因此Stream API也会将其发送到ForkJoinPool。不好的是，Stream API认为，前四个任务的进一步拆分是无用的，因为它们的估计大小要少得多。所以你得到的是非常不均匀的分割输入，最多使用四个CPU内核(即使你有更多)。如果您的每个元素处理对于任何元素大致相同，那么整个过程将等待最大的部分(3072个元素)完成。所以最大加速你可能有7000/3072 = 2.28x。因此，如果顺序处理需要41秒，则并行流将占用大约41 / 2.28 = 18秒(这与实际数字相近)。

你的解决方案是完全正常的。请注意，使用Files.list()。parallel()，您还可以将所有输入的Path元素存储在内存中(在ArraySpliterator对象中)。因此，如果您手动将其转储到列表中，则不会浪费更多内存。 ArrayList支持的列表实现(目前由Collectors.toList()创建)可以均匀分割，无任何问题，这将加快速度。

为什么没有优化这种情况？当然这不是不可能的问题(尽管实施可能相当棘手)。 JDK开发人员似乎不是高优先级的问题。邮件列表中有关于此主题的几个讨论。您可以阅读Paul Sandoz的消息here，在那里他对我的优化工作发表了意见。