参数类型

T - 此Spliterator返回的元素类型

All Known Subinterfaces:

Spliterator.OfDouble ， Spliterator.OfInt ， Spliterator.OfLong ， Spliterator.OfPrimitive<T,​T_CONS,​T_SPLITR>

所有已知实现类：

Spliterators.AbstractDoubleSpliterator ， Spliterators.AbstractIntSpliterator ， Spliterators.AbstractLongSpliterator ， Spliterators.AbstractSpliterator

public interface Spliterator<T>

API Note:

Spliterators，如Iterator ，用于遍历源的元素。 除了顺序遍历之外， Spliterator API还支持有效的并行遍历，支持分解以及单元素迭代。 此外，通过Spliterator访问元素的协议旨在施加比Iterator更小的每元素开销，并避免与hasNext()和next()具有单独方法相关的固有竞争。

对于可变源，如果源在Spliterator绑定到其数据源的时间与遍历结束之间受到结构干扰（元素添加，替换或删除），则可能会发生任意和非确定性行为。 例如，当使用java.util.stream框架时，此类干扰将产生任意的，不确定的结果。

源的结构干扰可以通过以下方式进行管理（大致降低合意性的顺序）：

• 源不能在结构上受到干扰。
  例如， CopyOnWriteArrayList的实例是不可变的源。 从源创建的IMMUTABLE报告IMMUTABLE的特征。
• 源管理并发修改。
  例如， ConcurrentHashMap的密钥集是并发源。 从源创建的CONCURRENT报告特征为CONCURRENT 。
• 可变源提供了后期绑定和失败快速的Spliterator。
  后期绑定使窗口变窄，在此期间干扰会影响计算; 在遍历开始并且抛出ConcurrentModificationException之后，在尽力而为的基础上快速检测到结构干扰已经发生。 例如， JDK中的ArrayList和许多其他非并发Collection类提供了一种后期绑定，失败快速的分裂器。
• 可变源提供非后期绑定但失败快速的Spliterator。
  由于潜在干扰窗口较大，因此增加投掷ConcurrentModificationException的可能性。
• 可变源提供了后期绑定和非故障快速Spliterator。
  由于未检测到干扰，在遍历开始之后，源会冒任意，非确定性行为。
• 可变源提供非后期绑定和非故障快速Spliterator。
  源增加了任意，非确定性行为的风险，因为在构造之后可能发生未检测到的干扰。

例。 这是一个类（不是非常有用的，除了插图），它维护一个数组，其中实际数据保存在偶数位置，而不相关的标签数据保存在奇数位置。 它的Spliterator忽略标签。

   class TaggedArray<T> { private final Object[] elements; // immutable after construction TaggedArray(T[] data, Object[] tags) { int size = data.length; if (tags.length != size) throw new IllegalArgumentException(); this.elements = new Object[2 * size]; for (int i = 0, j = 0; i < size; ++i) { elements[j++] = data[i]; elements[j++] = tags[i]; } } public Spliterator<T> spliterator() { return new TaggedArraySpliterator<>(elements, 0, elements.length); } static class TaggedArraySpliterator<T> implements Spliterator<T> { private final Object[] array; private int origin; // current index, advanced on split or traversal private final int fence; // one past the greatest index TaggedArraySpliterator(Object[] array, int origin, int fence) { this.array = array; this.origin = origin; this.fence = fence; } public void forEachRemaining(Consumer<? super T> action) { for (; origin < fence; origin += 2) action.accept((T) array[origin]); } public boolean tryAdvance(Consumer<? super T> action) { if (origin < fence) { action.accept((T) array[origin]); origin += 2; return true; } else // cannot advance return false; } public Spliterator<T> trySplit() { int lo = origin; // divide range in half int mid = ((lo + fence) >>> 1) & ~1; // force midpoint to be even if (lo < mid) { // split out left half origin = mid; // reset this Spliterator's origin return new TaggedArraySpliterator<>(array, lo, mid); } else // too small to split return null; } public long estimateSize() { return (long)((fence - origin) / 2); } public int characteristics() { return ORDERED | SIZED | IMMUTABLE | SUBSIZED; } } } 

作为一个例子，并行计算框架（如java.util.stream包）将如何在并行计算中使用Spliterator，这是实现关联并行forEach的一种方法，它说明了在估计工作量之前拆分子任务的主要用法习惯用法小到足以按顺序执行。 这里我们假设跨子任务的处理顺序无关紧要; 不同（分叉）任务可以以不确定的顺序进一步分割和处理元素。 这个例子使用了CountedCompleter ; 类似的用法适用于其他并行任务结构。

   static <T> void parEach(TaggedArray<T> a, Consumer<T> action) { Spliterator<T> s = a.spliterator(); long targetBatchSize = s.estimateSize() / (ForkJoinPool.getCommonPoolParallelism() * 8); new ParEach(null, s, action, targetBatchSize).invoke(); } static class ParEach<T> extends CountedCompleter<Void> { final Spliterator<T> spliterator; final Consumer<T> action; final long targetBatchSize; ParEach(ParEach<T> parent, Spliterator<T> spliterator, Consumer<T> action, long targetBatchSize) { super(parent); this.spliterator = spliterator; this.action = action; this.targetBatchSize = targetBatchSize; } public void compute() { Spliterator<T> sub; while (spliterator.estimateSize() > targetBatchSize && (sub = spliterator.trySplit()) != null) { addToPendingCount(1); new ParEach<>(this, sub, action, targetBatchSize).fork(); } spliterator.forEachRemaining(action); propagateCompletion(); } } 

Implementation Note:

如果布尔系统属性 org.openjdk.java.util.stream.tripwire设置为 true则在对原始子类型特化进行操作时，如果出现原始值的装箱，则会报告诊断警告。

从以下版本开始：

1.8

另请参见：

Collection