问题标签 [spliterator]

我注意到以下场景中的一些奇怪行为：

迭代器 -> 流 -> map() -> 迭代器() -> 迭代

原始迭代器的 hasNext() 在已经返回 false 之后再调用一次。

这是正常的吗？

如果我删除 map() 或将最终的 itearator() 替换为 count() 或 collect() 之类的东西，它就可以在没有冗余调用的情况下工作。

输出

java.util.Spliterator 我在(Java 8)中偶然发现了一个有趣的细节。

方法 trySplit() 应该返回 Spliterator 的实例，或者null，如果它不能被拆分。Java 文档说以下内容：

在我看来，它是一个完美的使用场所java.util.Optional。根据javadoc：

有什么原因，为什么没有使用 Optional ？

谷歌搜索并没有太大帮助，除了 lambda-dev 邮件列表中的这个问题，没有得到回答。

我正在实现一个Spliterator通过trySplit()return明确限制并行化的方法null。实施是否会estimateSize()为此拆分器生成的流提供任何性能改进？还是估计的大小仅对并行化有用？

编辑：为了澄清，我特别询问估计大小。也就是说，我的分离器没有这个SIZED特性。

它是如何工作的？怎么能Consumer<? super Integer>投到IntConsumer？？

我将流分离器直接用于我正在编写的库中的低级操作。最近，当我使用流分离器和交错tryAdvance/trySplit调用时，我发现了非常奇怪的行为。这是一个演示问题的简单代码：

输出是

如您所见，在平面映射之后，我应该从1to获得有序的连续数字流9。我拆分了一次拆分器，所以它应该跳转到某个中间位置。接下来，我从中消耗一个元素并再次拆分它。之后我打印所有剩余的元素。我希望我将有几个来自流尾部的连续元素（可能是零个元素，也可以）。然而我得到的是5and 6，然后突然跳到9。

我知道目前在 JDK 中没有以这种方式使用拆分器：它们总是在遍历之前拆分。但是官方文档并没有明确禁止调用trySplitafter tryAdvance。

当我使用直接从集合、数组、生成的源等创建的拆分器时，从未观察到此问题。仅当拆分器是从具有中间flatMap.

所以问题是：我是否遇到了错误，或者在某处明确禁止以这种方式使用拆分器？

根据 的文档Spliterator#getComparator，它指出

如果此 Spliterator 的来源是SORTEDa Comparator，则返回 that Comparator。如果源是SORTED自然顺序，则返回 null。否则，如果源不是SORTED，则抛出IllegalStateException。

实施要求：

默认实现总是抛出IllegalStateException.

返回： a Comparator，或者null元素是否按自然顺序排序。

抛出：IllegalStateException- 如果分离器没有报告SORTED.

所以在运行这段代码的时候

我得到：

到目前为止，一切都很好。现在这样做时：

它输出false并抛出异常：

为什么它输出false并抛出异常？

根据文档，它不应该给我Comparator我提供给的东西吗？sorted()

（这也发生在reverseOrder(), 或comparing(identity())等处）。

我有一个从 1 到 10,000 的数字存储在long. 按顺序添加它们时，结果为 50,005,000。
我写了一个 Spliterator，如果数组的大小超过 1000，它将被拆分到另一个数组。这是我的代码。但是当我运行它时，加法的结果远远大于 50,005,000。有人可以告诉我我的代码有什么问题吗？

非常感谢。

假设我们有一个也实现了拆分器的数据结构。用于测试使用该拆分器的并行处理是否实际上比顺序处理更好的样板代码是什么？

我知道在设置并行处理时存在开销，Stream如果项目很少或每个项目的处理速度很快，单线程中的处理速度会更快。

但是，是否有类似的阈值trySplit()，将问题分解成更小的块会适得其反？我通过类比来思考合并排序切换到最小块的插入排序。

如果是这样，阈值是否取决于在过程中的相对成本trySplit()和消费项目tryAdvance()？考虑一个比推进数组索引复杂得多的拆分操作——例如拆分一个按词法排序的多集排列。是否有约定让客户端在创建并行流时根据其使用者的复杂性指定拆分的下限？Spliterator可以用来估计下限本身的启发式方法吗？

或者，让 a 的下限为Spliterator1 并让工作窃取算法负责选择是否继续拆分是否总是安全的？

This is a classic implementation of an immutable linked list:

The default implementation of spliterator() does not support efficient parallelizing:

This will print 1, 2, 3 sequentially.

How to implement spliterator() to support efficient parallelizing?