用 Java 8 Streams 替换传统的 newForLoop

Question

所以，我终于从 Java 6 到 Java 8 有了较大的飞跃，我已经阅读了相当多的 Java 8 Streams API。不幸的是，几乎所有被问到的例子都几乎接近我试图弄清楚如何做的事情，但还不够接近。

我拥有的是

final List<Function<? super Double, Double>> myList = generateList();
final double myVal = calculate(10);

private double calculate(double val) {
    for (Function<? super Double, Double> function : this.myList) {
        val += function.apply(val);
    }
    return val;
}

现在，我开始明白我可以用 .stream().forEach() 做类似的事情，但这仅适用于 foreach 并且流需要最终变量。我尝试使用DoubleStream 进行一些探索以获得sum()，但我需要将当前总和重新应用于每个Function 并将该总和添加到下一个函数，如上面的代码示例显示。

纯 Stream API 可以做到这一点吗？

编辑：所以在使用reduce() 区域进行测试后，我对执行此类计算所需的时间进行了一个简单的测试，结果不利于流。这是一个例子https://gist.github.com/gabizou/33f616c08bde5ab97e56。包括来自相当基本测试的日志输出。

Answer 1

您可以使用流 API 从您的函数列表中组合一个函数。

static List<Function<? super Double, Double>> myList
    = Arrays.asList(d -> d + 4, d -> d * 2, d -> d - 3);

static Function<Double, Double> total=myList.stream()
    .map(f -> (Function<Double, Double>) d -> d + f.apply(d))
    .reduce(Function::andThen).orElse(Function.identity());

static double calculate(double val) {
    return total.apply(val);
}

public static void main(String[] args) {
    System.out.println(calculate(10));
}

产生组合函数的流操作不存在关联性问题，理论上甚至可以并行运行（尽管这里没有任何好处），而结果是单个函数，它本身是连续的，从不分解为部分这需要是关联的。

Answer 2

是的，您可以通过执行缩减来使用流解决方案：

private double calculate(double val) {
    return myList.stream().reduce(val, (d, f) -> d + f.apply(d), (a, b) -> a + b);
}

归约获取每个元素并将其聚合（归约）为一个值。 reduce() 方法有 3 种风格 - 这里使用的一种可以解决问题。

---

一些测试代码：

static Function<? super Double, Double> a = (d) -> d + 4;
static Function<? super Double, Double> b = (d) -> d * 2;
static Function<? super Double, Double> c = (d) -> d - 3;
static List<Function<? super Double, Double>> myList = Arrays.asList(a, b, c);

static double calculate(double val) {
    return myList.stream().reduce(val, (d, f) -> d + f.apply(d), (a, b) -> a + b);
}

public static void main(String[] args) {
    System.out.println(calculate(10));
}

输出：

141.0

Answer 3

这个特定的例子对于 Java 8 流来说是非常有问题的。它们专为顺序不重要的操作而设计。

函数应用程序不是关联的。为了解释，让我们举一个更简单的例子，其中一个人想要取一个数字并将其除以一个数字列表：

static List<Double> dividers = Arrays.asList( 3.5, 7.0, 0.5, 19.0 );

public double divideByList( double a ) {
    for ( Double d : dividers ) {
        a /= d;
    }
    return a;
}

所以，你得到的是

a ÷ 3.5 ÷ 7.0 ÷ 0.5 ÷ 19.0

算术很简单 - 除法是左结合的，这意味着这等价于

a ÷ ( 3.5 × 7.0 × 0.5 × 19.0)

不是

a ÷ ( 3.5 ÷ 7.0 ÷ 0.5 ÷ 19.0 )

而不是

( a ÷ 3.5 ÷ 7.0 ) ÷ ( 0.5 ÷ 19.0 )

基于reduce/collectors 的流操作要求“reducing”操作是左关联的。这是因为他们想让操作被并行化，这样一些线程会做一些操作，然后可以合并结果。现在，如果您的 our 运算符是乘法而不是除法，这将不是问题，因为

a × 3.5 × 7.0 × 0.5 × 19.0

与

相同

(a × 3.5 × 7.0 ) × (0.5 × 19)

这意味着一个线程可以执行a × 3.5 × 7.0，另一个可以执行0.5 × 19.0 操作，然后您可以将结果相乘并得到与顺序计算相同的结果。但是对于除法，这是行不通的。

函数应用也是非关联的，就像除法一样。也就是说，如果您有函数f、g 和h，并运行顺序计算，您将得到：

result = val + f(val) + g(val + f(val)) + h(val + f(val) + g(val + f(val)))

现在，如果您有两个中间线程，一个应用f 和g，另一个应用h，并且您想要组合结果 - 没有办法将正确的值放入@首先是987654340@。

---

您可能很想尝试使用Stream.reduce 之类的方法，正如@Bohemian 所建议的那样。但是documentation 警告您不要这样做：

<U> U reduce(U identity,
             BiFunction<U,? super T,U> accumulator,
             BinaryOperator<U> combiner)

...

标识值必须是组合器函数的标识。这意味着对于所有 u，combiner(identity, u) 等于 u。此外，combiner 函数必须与 accumulator 函数兼容；对于所有 u 和 t，必须满足以下条件：

combiner.apply(u, accumulator.apply(identity, t)) == accumulator.apply(u, t)

对于像+ 这样的操作，标识为0。对于*，标识为1。因此，将val 用作identity 是违反文档的。而第二个条件就更成问题了。

虽然非并行流的当前实现不使用 combiner 部分，这使得这两个条件都不需要，这没有记录 strong>，未来的实现或不同的 JRE 实现可能会决定创建中间结果并使用 combiner 来加入它们，可能是为了提高性能或出于任何其他考虑。

因此，尽管有诱惑，但应该不使用Stream.reduce 来尝试模仿最初的顺序处理。

---

有一种方法可以做到这一点，实际上并不会破坏文档。它涉及保留一个保存结果的可变对象（它必须是一个对象，以便它在仍然可变的同时有效地最终确定），并使用Stream.forEachOrdered，它保证操作将按照它们在流中出现的顺序执行, 如果流是有序的。并且列表的流具有定义的顺序。即使您使用myList.stream().parallel()，这也有效。

public static double streamedCalculate(double val) {
    class MutableDouble {
        double currVal;
        MutableDouble(double initVal) {
            currVal = initVal;
        }
    }

    final MutableDouble accumulator = new MutableDouble(val);

    myList.stream().forEachOrdered((x) -> accumulator.currVal += x.apply(accumulator.currVal));
    return accumulator.currVal;
}

就个人而言，我发现您的原始循环比这更具可读性，因此在这里使用流确实没有任何优势。

根据@Tagir Valeev 的评论，计划在未来的Java 版本中使用foldLeft 操作。发生这种情况时，它可能看起来更优雅。