为什么Java流是一次性的?

流是围绕spliterator构建的，spliterator是有状态的、可变的对象。它们没有“重置”操作，事实上，要求支持这样的倒带操作会“消耗很多能量”。random .int()应该如何处理这样的请求?

另一方面，对于具有可追溯起源的流，很容易构造一个等价的流来再次使用。只需将构造Stream的步骤放到可重用方法中。请记住，重复这些步骤并不是一个昂贵的操作，因为所有这些步骤都是惰性操作;实际的工作从终端操作开始，根据实际的终端操作，可能会执行完全不同的代码。

这将由这种方法的作者来指定两次调用该方法意味着什么:它是否会像为未修改的数组或集合创建的流那样完全复制相同的序列，或者它是否会生成具有类似语义但元素不同的流，例如随机整数流或控制台输入行流，等等。

顺便说一下，为了避免混淆，终端操作消耗的是流，而不是像在流上调用close()那样关闭流(这对于具有关联资源的流来说是必需的，例如由Files.lines()产生)。

It seems that a lot of confusion stems from misguiding comparison of IEnumerable with Stream. An IEnumerable represents the ability to provide an actual IEnumerator, so its like an Iterable in Java. In contrast, a Stream is a kind of iterator and comparable to an IEnumerator so it’s wrong to claim that this kind of data type can be used multiple times in .NET, the support for IEnumerator.Reset is optional. The examples discussed here rather use the fact that an IEnumerable can be used to fetch new IEnumerators and that works with Java’s Collections as well; you can get a new Stream. If the Java developers decided to add the Stream operations to Iterable directly, with intermediate operations returning another Iterable, it was really comparable and it could work the same way.

However, the developers decided against it and the decision is discussed in this question. The biggest point is the confusion about eager Collection operations and lazy Stream operations. By looking at the .NET API, I (yes, personally) find it justified. While it looks reasonable looking at IEnumerable alone, a particular Collection will have lots of methods manipulating the Collection directly and lots of methods returning a lazy IEnumerable, while the particular nature of a method isn’t always intuitively recognizable. The worst example I found (within the few minutes I looked at it) is List.Reverse() whose name matches exactly the name of the inherited (is this the right terminus for extension methods?) Enumerable.Reverse() while having an entirely contradicting behavior.

当然，这是两个截然不同的决定。第一个是使Stream成为一种不同于Iterable/Collection的类型，第二个是使Stream成为一种一次性迭代器而不是另一种迭代器。但这些决定是一起做出的，可能从来没有考虑过把这两个决定分开。它在创建时并没有考虑到与. net的可比性。

实际的API设计决策是添加一种改进的迭代器类型，即Spliterator。分离器可以由旧的Iterables提供(这是它们被改造的方式)，也可以由全新的实现提供。然后，Stream作为高级前端添加到相当低级的Spliterators中。就是这样。你可能会讨论不同的设计是否会更好，但这并没有什么成效，考虑到它们现在的设计方式，它不会改变。

There is another implementation aspect you have to consider. Streams are not immutable data structures. Each intermediate operation may return a new Stream instance encapsulating the old one but it may also manipulate its own instance instead and return itself (that doesn’t preclude doing even both for the same operation). Commonly known examples are operations like parallel or unordered which do not add another step but manipulate the entire pipeline). Having such a mutable data structure and attempts to reuse (or even worse, using it multiple times at the same time) doesn’t play well…

为了完整起见，下面是翻译成Java流API的快速排序示例。这表明它并没有真正“带走太多的能量”。

static Stream<Integer> quickSort(Supplier<Stream<Integer>> ints) {

  final Optional<Integer> optPivot = ints.get().findAny();
  if(!optPivot.isPresent()) return Stream.empty();

  final int pivot = optPivot.get();

  Supplier<Stream<Integer>> lt = ()->ints.get().filter(i -> i < pivot);
  Supplier<Stream<Integer>> gt = ()->ints.get().filter(i -> i > pivot);

  return Stream.of(quickSort(lt), Stream.of(pivot), quickSort(gt)).flatMap(s->s);
}

它可以像这样使用

List<Integer> l=new Random().ints(100, 0, 1000).boxed().collect(Collectors.toList());
System.out.println(l);
System.out.println(quickSort(l::stream)
    .map(Object::toString).collect(Collectors.joining(", ")));

你可以把它写得更紧凑

static Stream<Integer> quickSort(Supplier<Stream<Integer>> ints) {
    return ints.get().findAny().map(pivot ->
         Stream.of(
                   quickSort(()->ints.get().filter(i -> i < pivot)),
                   Stream.of(pivot),
                   quickSort(()->ints.get().filter(i -> i > pivot)))
        .flatMap(s->s)).orElse(Stream.empty());
}

2015-02-11 17:11:27

我认为当你仔细观察时，两者之间几乎没有什么区别。

从表面上看，IEnumerable确实是一个可重用的结构:

IEnumerable<int> numbers = new int[] { 1, 2, 3, 4, 5 };

foreach (var n in numbers) {
    Console.WriteLine(n);
}

然而，编译器实际上做了一些工作来帮助我们;它生成以下代码:

IEnumerable<int> numbers = new int[] { 1, 2, 3, 4, 5 };

IEnumerator<int> enumerator = numbers.GetEnumerator();
while (enumerator.MoveNext()) {
    Console.WriteLine(enumerator.Current);
}

每次迭代枚举对象时，编译器都会创建一个枚举对象。枚举数不可重用;进一步调用MoveNext将返回false，并且没有办法将其重置到开始。如果希望再次遍历这些数字，则需要创建另一个枚举器实例。

为了更好地说明IEnumerable具有(可以具有)与Java流相同的“特性”，可以考虑一个数字源不是静态集合的enumerable。例如，我们可以创建一个可枚举对象，它生成一个由5个随机数组成的序列:

class Generator : IEnumerator<int> {
    Random _r;
    int _current;
    int _count = 0;

    public Generator(Random r) {
        _r = r;
    }

    public bool MoveNext() {
        _current= _r.Next();
        _count++;
        return _count <= 5;
    }

    public int Current {
        get { return _current; }
    }
 }

class RandomNumberStream : IEnumerable<int> {
    Random _r = new Random();
    public IEnumerator<int> GetEnumerator() {
        return new Generator(_r);
    }
    public IEnumerator IEnumerable.GetEnumerator() {
        return this.GetEnumerator();
    }
}

现在我们有了与之前基于数组的enumerable非常相似的代码，但是对数字进行了第二次迭代:

IEnumerable<int> numbers = new RandomNumberStream();

foreach (var n in numbers) {
    Console.WriteLine(n);
}
foreach (var n in numbers) {
    Console.WriteLine(n);
}

第二次对数字进行迭代时，我们将得到一个不同的数字序列，这在同一意义上不是可重用的。或者，我们可以编写RandomNumberStream来抛出一个异常，如果您尝试多次遍历它，使可枚举对象实际上不可用(就像Java流)。

同样，当应用于RandomNumberStream时，基于枚举的快速排序意味着什么?

结论

因此，最大的区别是。net允许你在需要访问序列中的元素时在后台隐式地创建一个新的IEnumerator来重用IEnumerable。

这种隐式行为通常是有用的(正如你所说的“强大”)，因为我们可以重复迭代一个集合。

但有时，这种内隐行为实际上会导致问题。如果你的数据源不是静态的，或者访问成本很高(比如数据库或网站)，那么很多关于IEnumerable的假设必须被丢弃;重用并不是那么简单

2015-02-11 22:18:13