You should almost certainly never have to deal with Spliterator
as a user; it should only be necessary if you're writing Collection
types yourself and also intending to optimize parallelized operations on them.
For what it's worth, a Spliterator
is a way of operating over the elements of a collection in a way that it's easy to split off part of the collection, e.g. because you're parallelizing and want one thread to work on one part of the collection, one thread to work on another part, etc.
You should essentially never be saving values of type Stream
to a variable, either. Stream
is sort of like an Iterator
, in that it's a one-time-use object that you'll almost always use in a fluent chain, as in the Javadoc example:
int sum = widgets.stream()
.filter(w -> w.getColor() == RED)
.mapToInt(w -> w.getWeight())
.sum();
Collector
is the most generalized, abstract possible version of a "reduce" operation a la map/reduce; in particular, it needs to support parallelization and finalization steps. Examples of Collector
s include:
- summing, e.g.
Collectors.reducing(0, (x, y) -> x + y)
- StringBuilder appending, e.g.
Collector.of(StringBuilder::new, StringBuilder::append, StringBuilder::append, StringBuilder::toString)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…