Spliterator (Java SE 9 & JDK 9 ) (original) (raw)

public interface Spliterator
An object for traversing and partitioning elements of a source. The source of elements covered by a Spliterator could be, for example, an array, aCollection, an IO channel, or a generator function.
A Spliterator may traverse elements individually (tryAdvance()) or sequentially in bulk (forEachRemaining()).
A Spliterator may also partition off some of its elements (usingtrySplit()) as another Spliterator, to be used in possibly-parallel operations. Operations using a Spliterator that cannot split, or does so in a highly imbalanced or inefficient manner, are unlikely to benefit from parallelism. Traversal and splitting exhaust elements; each Spliterator is useful for only a single bulk computation.
A Spliterator also reports a set of characteristics() of its structure, source, and elements from among ORDERED,DISTINCT, SORTED, SIZED, NONNULL,IMMUTABLE, CONCURRENT, and SUBSIZED. These may be employed by Spliterator clients to control, specialize or simplify computation. For example, a Spliterator for a Collection would report SIZED, a Spliterator for a Set would reportDISTINCT, and a Spliterator for a SortedSet would also report SORTED. Characteristics are reported as a simple unioned bit set. Some characteristics additionally constrain method behavior; for example ifORDERED, traversal methods must conform to their documented ordering. New characteristics may be defined in the future, so implementors should not assign meanings to unlisted values.
A Spliterator that does not report IMMUTABLE orCONCURRENT is expected to have a documented policy concerning: when the spliterator binds to the element source; and detection of structural interference of the element source detected after binding. A_late-binding_ Spliterator binds to the source of elements at the point of first traversal, first split, or first query for estimated size, rather than at the time the Spliterator is created. A Spliterator that is not late-binding binds to the source of elements at the point of construction or first invocation of any method. Modifications made to the source prior to binding are reflected when the Spliterator is traversed. After binding a Spliterator should, on a best-effort basis, throwConcurrentModificationException if structural interference is detected. Spliterators that do this are called fail-fast. The bulk traversal method (forEachRemaining()) of a Spliterator may optimize traversal and check for structural interference after all elements have been traversed, rather than checking per-element and failing immediately.
Spliterators can provide an estimate of the number of remaining elements via the estimateSize() method. Ideally, as reflected in characteristicSIZED, this value corresponds exactly to the number of elements that would be encountered in a successful traversal. However, even when not exactly known, an estimated value may still be useful to operations being performed on the source, such as helping to determine whether it is preferable to split further or traverse the remaining elements sequentially.
Despite their obvious utility in parallel algorithms, spliterators are not expected to be thread-safe; instead, implementations of parallel algorithms using spliterators should ensure that the spliterator is only used by one thread at a time. This is generally easy to attain via serial thread-confinement, which often is a natural consequence of typical parallel algorithms that work by recursive decomposition. A thread callingtrySplit() may hand over the returned Spliterator to another thread, which in turn may traverse or further split that Spliterator. The behaviour of splitting and traversal is undefined if two or more threads operate concurrently on the same spliterator. If the original thread hands a spliterator off to another thread for processing, it is best if that handoff occurs before any elements are consumed with tryAdvance(), as certain guarantees (such as the accuracy ofestimateSize() for SIZED spliterators) are only valid before traversal has begun.
Primitive subtype specializations of Spliterator are provided forint, long, and double values. The subtype default implementations oftryAdvance(java.util.function.Consumer) and forEachRemaining(java.util.function.Consumer) box primitive values to instances of their corresponding wrapper class. Such boxing may undermine any performance advantages gained by using the primitive specializations. To avoid boxing, the corresponding primitive-based methods should be used. For example,Spliterator.OfInt.tryAdvance(java.util.function.IntConsumer) and Spliterator.OfInt.forEachRemaining(java.util.function.IntConsumer) should be used in preference toSpliterator.OfInt.tryAdvance(java.util.function.Consumer) andSpliterator.OfInt.forEachRemaining(java.util.function.Consumer). Traversal of primitive values using boxing-based methodstryAdvance() andforEachRemaining() does not affect the order in which the values, transformed to boxed values, are encountered.
API Note:
Spliterators, like Iterators, are for traversing the elements of a source. The Spliterator API was designed to support efficient parallel traversal in addition to sequential traversal, by supporting decomposition as well as single-element iteration. In addition, the protocol for accessing elements via a Spliterator is designed to impose smaller per-element overhead than Iterator, and to avoid the inherent race involved in having separate methods for hasNext() andnext().
For mutable sources, arbitrary and non-deterministic behavior may occur if the source is structurally interfered with (elements added, replaced, or removed) between the time that the Spliterator binds to its data source and the end of traversal. For example, such interference will produce arbitrary, non-deterministic results when using the java.util.stream framework.
Structural interference of a source can be managed in the following ways (in approximate order of decreasing desirability): 

 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:
If the boolean system property org.openjdk.java.util.stream.tripwire is set to true then diagnostic warnings are reported if boxing of primitive values occur when operating on primitive subtype specializations.
Since:
1.8
See Also:
Collection