问题标签 [spliterator]

https://docs.oracle.com/javase/8/docs/api/java/util/Spliterator.html

SIZED 特征值，表示在遍历或拆分之前从estimateSize() 返回的值表示有限大小，在没有结构源修改的情况下，表示完整遍历将遇到的元素数量的精确计数。

SUBSIZED 特征值，表示由 trySplit() 产生的所有拆分器都将是 SIZED 和 SUBSIZED。

1. 是否存在 SIZED 标志打开但 SUBSIZED 标志关闭的情况？
2. 是否存在 SUBSIZED 标志打开但 SIZED 标志关闭的情况？

订购

流可能有也可能没有定义的相遇顺序。流是否有遇到顺序取决于源和中间操作。某些流源（例如 List 或数组）本质上是有序的，而其他流源（例如 HashSet）则不是。一些中间操作，例如 sorted()，可能会对原本无序的流施加遇到顺序，而其他操作可能会使有序流呈现无序，例如 BaseStream.unordered()。此外，某些终端操作可能会忽略遇到顺序，例如 forEach()。

1. 是否有任何其他类型不具有遇到顺序属性但是HashSet？
2. 如果我对保持现有顺序或任何排序不感兴趣，通过显式调用unordered将并行计算的每个流上的中间操作是否被认为是最佳实践？

我正在查看 Spliterator 的文档，根据它，Spliterator 不是线程安全的：

尽管它们在并行算法中有明显的用途，但分离器并不期望是线程安全的。相反，使用拆分器的并行算法的实现应确保拆分器一次仅由一个线程使用。这通常很容易通过串行线程限制来实现，这通常是通过递归分解工作的典型并行算法的自然结果。

但是，在其进一步的文档中，与上述声明相矛盾：

可以通过以下方式管理源的结构干扰（按合意性递减的大致顺序）：

源管理并发修改。例如，java.util.concurrent.ConcurrentHashMap 的键集是一个并发源。从源创建的 Spliterator 报告 CONCURRENT 的特征。

那么这是否意味着从线程安全集合生成的 Spliterator 将是线程安全的？这样对吗？

哪些流操作使用CONCURRENT,IMMUTABLE和NONNULLSpliterator 特征？他们每个人如何帮助这些操作？

我不是在问那些标志是什么，这可以在文档中很容易地找到。我在问哪些操作使用它们以及如何使用它们。

我试图了解每个操作的拆分器到底在迭代什么。如果我错了，请纠正我：（我很可能是错的）

1. 每个流都有.spliterator()方法。
2. 每个中间操作都可以改变分离器的特性。

我的问题：

1. 每个中间操作是否使用和更改同一拆分器（“源拆分器”）中的特征？
2. 如果我们使用filter操作，那么可以省略一些元素。这些元素究竟是从哪个集合中省略的？

我正在创建一个旨在研究具有任意大初始项的 Collat​​z 序列的课程。由于项的大小和结果序列的长度，给定序列的项不会存储在其对应的实例中，但可以迭代。

当然，生成函数对于序列的每次遍历都以相同的顺序返回相同的项，因此它在技术上是有序的。但是，我在以下文档中看到了这一点Spliterator.ORDERED：

我无法以这种方式明确定义序列的相遇顺序，只能确定它存在。我还能举报Spliterator.ORDERED吗？

注意：我没有实施List. 我只是使用上面的引用作为我无法提供的那种显式排序定义的一个例子。

我最近发现了一个错误，其中

被调用Spliterator.ofInt.tryAdvance超过 20 次。当我将其更改为

问题消失了。为什么会这样？tryAdvance当有副作用时，有什么方法可以对并行流进行严格限制，而不是在Spliterator? （这是为了测试一些返回无限流的方法，但是测试需要在没有“X 毫秒循环”构造的复杂情况下达到最终结束。）

我有一个简单的 JSONObject

现在我希望将其转换为地图，所以我写道：

obj 是JSONObject的一个实例。obj.keys()返回一个Iterator并且obj.get()返回这个键的值。

为什么我会收到错误消息？如何以实用的方式修复它？

为了尝试深入理解 java 流和拆分器，我对拆分器特性有一些微妙的问题：

Q1：Stream.empty()vsStream.of()（没有参数的Stream.of（））

• Stream.empty():缩小的, 大小的
• Stream.of(): SUBSIZED, IMMUTABLE , SIZED, ORDERED

为什么Stream.empty()没有相同的特征Stream.of()？请注意，与 Stream.concat() 结合使用时会产生影响（特别是没有ORDERED）。我想说这Stream.empty()不仅应该有IMMUTABLE 和 ORDERED，还应该有DISTINCT 和 NONNULL。Stream.of()只有一个参数具有DISTICT 也是有意义的。

Q2：LongStream.of()没有NONNULL

刚刚注意到 NONNULL 在LongStream.of. 不是NONNULL所有LongStreams，IntStreams和DoubleStreams的主要特征吗？

Q3：LongStream.range(,)对比LongStream.range(,).boxed()

• LongRange.range(,): SUBSIZED, IMMUTABLE, NONNULL , SIZED, ORDERED, SORTED , DISTINCT
• LongStream.range(,).boxed():已订制、已订制、已订制

为什么.boxed()会失去所有这些特征？它不应该失去任何东西。

我知道这.mapToObj()可能会丢失NONNULL、IMMUTABLE 和 DISTICT，但是.boxed()......没有意义。

Q4：.peek()丢失IMMUTABLE 和 NONNULL

LongStream.of(1): SUBSIZED, IMMUTABLE, NONNULL, SIZED, ... LongStream.of(1).peek() : SUBSIZED, SIZED, ...

为什么.peek()会失去这些特征？.peek不应该真的失去任何东西。

Q5: .skip(),.limit()丢失SUBSIZED, IMMUTABLE, NONNULL, SIZED

请注意，这些操作会丢失SUBSIZED, IMMUTABLE, NONNULL, SIZED。为什么？如果尺寸可用，那么计算最终尺寸也很容易。

Q6:.filter()丢失IMMUTABLE, NONNULL

请注意，此操作也会丢失SUBSIZED, IMMUTABLE, NONNULL, SIZED。丢失SUBSIZED 和 SIZED是有意义的，但其他两个没有意义。为什么？

如果深入了解拆分器的人可以带来一些清晰度，我将不胜感激。谢谢。

在第一个关于深入理解 Java 流拆分器的问题之后，另一个关于流的微妙问题：为什么.flatMap()Java 中的实现效率如此低下（非懒惰）？

通常流应该尽可能地懒惰，但.flatMap()方法不是。

例如：

stream.flatMap(this::getStreamWith10HeavyComputationElems).firstFirst()在返回第一个重计算结果之前将消耗 10 个元素（10 个重计算）。

stream.flatMap(this::getStreamWith10HeavyComputationElems).limit(11).count()在返回 11 之前将消耗 20 个元素（2x10 繁重的计算）。

问题是为什么 Java使用非惰性实现？

作为解决方法，我创建了自己的 flatMap 实现，但与 native 调用相比它缺乏流畅性：flatMap(stream, mapper)vs native stream.flatMap(mapper)。