以下哪一项是Java 8中更好的实践方法？
Java 8：
joins.forEach(join -> mIrc.join(mSession, join));
Java 7：
for (String join : joins) {
mIrc.join(mSession, join);
}
我有很多可以用lambda“简化”的for循环，但是使用它们真的有任何优势吗？会提高它们的性能和可读性吗？
编辑
我还将这个问题扩展到更长的方法。我知道你不能从lambda返回或中断父函数，当比较它们时也应考虑到这一点，但还有其他需要考虑的因素吗？
for-each。除了违反“保持简单愚蠢”原则外，新式的forEach()至少存在以下缺陷：
Object prev = null;
for(Object curr : list)
{
if( prev != null )
foo(prev, curr);
prev = curr;
}
无法处理已检查异常。Lambda 表达式并不禁止抛出已检查异常，但常见的函数式接口（如 Consumer）没有声明任何异常。因此，任何抛出已检查异常的代码都必须将其包装在 try-catch 或 Throwables.propagate() 中。但即使你这样做了，抛出的异常的去向也不总是清晰的。它可能会在 forEach() 的内部某处被吞噬。
流程控制有限。Lambda 中的 return 相当于 for-each 中的 continue，但没有与 break 相对应的等价物。同时，像返回值、短路或设置标志这样的操作也很困难（如果不违反“无非终态变量”规则，这将稍微缓解一些问题）。“这不仅仅是优化问题，而且在考虑到某些序列（例如读取文件中的行）可能具有副作用，或者你可能有一个无限序列时，这更是至关重要的。”
可能会并行执行，这对于除了需要进行优化的 0.1% 的代码之外的所有代码来说都是可怕的事情。任何并行代码都必须经过深思熟虑（即使它不使用锁、易失性和传统多线程执行的其他特别恶劣的方面）。任何错误都将很难找到。
可能会影响性能，因为 JIT 无法像普通循环一样对 forEach()+lambda 进行优化，尤其是现在 lambda 是新的。所谓“优化”并不是指调用 lambda 的开销（这很小），而是指现代 JIT 编译器对运行代码进行的复杂分析和转换。
如果确实需要并行处理，则使用 ExecutorService 可能更快且不太困难。流既是自动的（即不知道你的问题），又使用了专门的（即针对一般情况效率低下的）并行化策略（fork-join 递归分解）。
使调试更加混乱，因为存在嵌套的调用层次结构和并行执行。调试器可能无法显示周围代码中的变量，而像逐步执行之类的操作可能无法按预期工作。
总的来说，流更难编写、阅读和调试。实际上，这适用于复杂的“流畅”API。复杂的单语句、大量使用泛型以及缺乏中间变量的组合会产生令人困惑的错误消息，并使调试变得繁琐。与其说是“这个方法没有 X 类型的重载”，不如说是“你在某个地方搞错了类型，但我们不知道是哪里或者怎么搞错的。”同样，当代码分解为多个语句并将中间值保存到变量中时，无法像在此情况下那样轻松地通过调试器步进并检查事物。最后，阅读代码并理解每个执行阶段的类型和行为可能是非常棘手的
正如你所见，除非在有意义的情况下，否则我不是forEach()的忠实粉丝。
尤其让我反感的是，Stream没有实现Iterable（尽管实际上有iterator方法），不能在for-each中使用，只能使用forEach()。我建议使用(Iterable<T>)stream::iterator将Stream转换为Iterable。更好的选择是使用StreamEx，它解决了一些Stream API的问题，包括实现Iterable。
话虽如此，forEach()对以下情况很有用：
原子性地迭代同步列表。在此之前，使用Collections.synchronizedList()生成的列表在诸如获取或设置等方面具有原子性，但在迭代时不是线程安全的。
并行执行（使用适当的并行流）。如果您的问题符合 Streams 和 Spliterators 内置的性能假设，则与使用 ExecutorService 相比，这可以为您节省几行代码。
特定容器，例如同步列表，受益于控制迭代（尽管这在很大程度上是理论上的，除非人们能举出更多例子）。
通过使用 forEach() 和方法引用参数（即，list.forEach(obj::someMethod)）更清晰地调用单个函数。但是，请注意关于已检查异常、更难调试以及减少编写代码时使用的习语数量的要点。
我参考的文章：
编辑：看起来一些关于lambda的最初提案（例如http://www.javac.info/closures-v06a.html Google缓存）解决了我提到的一些问题（当然也增加了自己的复杂性）。
forEach存在的目的是鼓励使用不带副作用的表达式来实现函数式编程。如果你发现forEach与你的副作用无法很好地配合，那么你应该感到你没有使用正确的工具来完成任务。简单的答案是，那是因为你的感觉是正确的，所以对于那种情况，请继续使用for-each循环。传统的for循环并没有被弃用... - HolgerforEach如何在没有副作用的情况下使用？ - Aleksandr DubinskyforEach 是唯一一个旨在进行副作用的流操作，但它并不是像你的示例代码那样的副作用，计数是典型的 reduce 操作。我建议，作为一个经验法则，将每个操作都保留在传统的 for 循环中，这些操作会操作本地变量或影响控制流程（包括异常处理）。关于原始问题，我认为问题源于有人使用了一个流，而简单的 for 循环可以覆盖流的源。只有在 forEach() 起作用的情况下才使用流。 - HolgerforEach适合用于哪些会产生副作用的示例？ - Aleksandr Dubinskyfor循环工作。 - Holger当操作可以并行执行时，这种优势就会发挥作用。（请参见http://java.dzone.com/articles/devoxx-2012-java-8-lambda-and中关于内部和外部迭代的部分）
我认为最主要的优点是，在循环内定义要执行的任务实现，而不必决定它是并行还是顺序执行。
如果你想让你���循环并行执行，只需要写
joins.parallelStream().forEach(join -> mIrc.join(mSession, join));
你需要编写一些额外的代码来处理线程等内容。
注意：在我的回答中，我假设连接实现了java.util.Stream接口。如果连接仅实现了java.util.Iterable接口，则不再成立。
Stream#forEach 和 Iterable#forEach 不是同一件事情。OP 正在询问的是 Iterable#forEach。 - gvlasovjoins实现了Iterable而不是Stream，为什么这个答案无效？从我读过的一些东西来看，如果joins实现了Iterable，那么OP应该能够执行joins.stream().forEach((join) -> mIrc.join(mSession, join));和joins.parallelStream().forEach((join) -> mIrc.join(mSession, join));。 - BlueriverIterable#forEach是编写传统for-each循环的快捷方式/替代方法。但这并不是真的。来自OP的代码如下：joins.forEach(join -> mIrc.join(mSession, join));
不是用来快捷编写的
for (String join : joins) {
mIrc.join(mSession, join);
}
这种用法是不可取的，应该避免使用。它的本意是作为一种快捷方式（虽然并不完全相同），用于编写代码。
joins.forEach(new Consumer<T>() {
@Override
public void accept(T join) {
mIrc.join(mSession, join);
}
});
final Consumer<T> c = new Consumer<T>() {
@Override
public void accept(T join) {
mIrc.join(mSession, join);
}
};
for (T t : joins) {
c.accept(t);
}
既然这个线程已经讨论了 Iterable#forEach 的缺点，那么下面是一些你可能想使用 Iterable#forEach 的原因：
To make your code more explicit: As described above, Iterable#forEach can make your code more explicit and readable in some situations.
To make your code more extensible and maintainable: Using a function as the body of a loop allows you to replace this function with different implementations (see Strategy Pattern). You could e.g. easily replace the lambda expression with a method call, that may be overwritten by sub-classes:
joins.forEach(getJoinStrategy());
Then you could provide default strategies using an enum, that implements the functional interface. This not only makes your code more extensible, it also increases maintainability because it decouples the loop implementation from the loop declaration.
To make your code more debuggable: Seperating the loop implementation from the declaration can also make debugging more easy, because you could have a specialized debug implementation, that prints out debug messages, without the need to clutter your main code with if(DEBUG)System.out.println(). The debug implementation could e.g. be a delegate, that decorates the actual function implementation.
To optimize performance-critical code: Contrary to some of the assertions in this thread, Iterable#forEach does already provide better performance than a traditional for-each loop, at least when using ArrayList and running Hotspot in "-client" mode. While this performance boost is small and negligible for most use cases, there are situations, where this extra performance can make a difference. E.g. library maintainers will certainly want to evaluate, if some of their existing loop implementations should be replaced with Iterable#forEach.
To back this statement up with facts, I have done some micro-benchmarks with Caliper. Here is the test code (latest Caliper from git is needed):
@VmOptions("-server")
public class Java8IterationBenchmarks {
public static class TestObject {
public int result;
}
public @Param({"100", "10000"}) int elementCount;
ArrayList<TestObject> list;
TestObject[] array;
@BeforeExperiment
public void setup(){
list = new ArrayList<>(elementCount);
for (int i = 0; i < elementCount; i++) {
list.add(new TestObject());
}
array = list.toArray(new TestObject[list.size()]);
}
@Benchmark
public void timeTraditionalForEach(int reps){
for (int i = 0; i < reps; i++) {
for (TestObject t : list) {
t.result++;
}
}
return;
}
@Benchmark
public void timeForEachAnonymousClass(int reps){
for (int i = 0; i < reps; i++) {
list.forEach(new Consumer<TestObject>() {
@Override
public void accept(TestObject t) {
t.result++;
}
});
}
return;
}
@Benchmark
public void timeForEachLambda(int reps){
for (int i = 0; i < reps; i++) {
list.forEach(t -> t.result++);
}
return;
}
@Benchmark
public void timeForEachOverArray(int reps){
for (int i = 0; i < reps; i++) {
for (TestObject t : array) {
t.result++;
}
}
}
}
And here are the results:
When running with "-client", Iterable#forEach outperforms the traditional for loop over an ArrayList, but is still slower than directly iterating over an array. When running with "-server", the performance of all approaches is about the same.
To provide optional support for parallel execution: It has already been said here, that the possibility to execute the functional interface of Iterable#forEach in parallel using streams, is certainly an important aspect. Since Collection#parallelStream() does not guarantee, that the loop is actually executed in parallel, one must consider this an optional feature. By iterating over your list with list.parallelStream().forEach(...);, you explicitly say: This loop supports parallel execution, but it does not depend on it. Again, this is a feature and not a deficit!
By moving the decision for parallel execution away from your actual loop implementation, you allow optional optimization of your code, without affecting the code itself, which is a good thing. Also, if the default parallel stream implementation does not fit your needs, no one is preventing you from providing your own implementation. You could e.g. provide an optimized collection depending on the underlying operating system, on the size of the collection, on the number of cores, and on some preference settings:
public abstract class MyOptimizedCollection<E> implements Collection<E>{
private enum OperatingSystem{
LINUX, WINDOWS, ANDROID
}
private OperatingSystem operatingSystem = OperatingSystem.WINDOWS;
private int numberOfCores = Runtime.getRuntime().availableProcessors();
private Collection<E> delegate;
@Override
public Stream<E> parallelStream() {
if (!System.getProperty("parallelSupport").equals("true")) {
return this.delegate.stream();
}
switch (operatingSystem) {
case WINDOWS:
if (numberOfCores > 3 && delegate.size() > 10000) {
return this.delegate.parallelStream();
}else{
return this.delegate.stream();
}
case LINUX:
return SomeVerySpecialStreamImplementation.stream(this.delegate.spliterator());
case ANDROID:
default:
return this.delegate.stream();
}
}
}
The nice thing here is, that your loop implementation doesn't need to know or care about these details.
forEach和for-each之间切换。智慧和遵守这些规则的纪律是一名优秀程序员的标志。这些规则也是他的灾难，因为他周围的人要么不遵守它们，要么持不同意见，例如使用已检查的异常和未检查的异常。这种情况似乎更加微妙。但是，如果循环体“不影响周围的代码或流程控制”，将其分解为一个函数是否更好呢？ - Aleksandr DubinskyIterable＃forEach 的函数式循环，只是因为它可以提高性能。所涉及的项目具有一个主循环，类似于游戏循环，并且有数量不确定的嵌套子循环，在其中客户端可以将循环参与者作为函数连接起来。这样的软件结构非常适合使用 Iterable＃forEach。 - BalderforEach() 可以被实现为比 for-each 循环更快，因为可迭代对象知道迭代其元素的最佳方法，而不是使用标准迭代器方式。因此，差别在于内部循环还是外部循环。
例如，ArrayList.forEach(action) 可以简单地实现为
for(int i=0; i<size; i++)
action.accept(elements[i])
与需要大量脚手架的 for-each 循环相反
Iterator iter = list.iterator();
while(iter.hasNext())
Object next = iter.next();
do something with `next`
然而，使用forEach()我们还需要考虑两个额外的开销，一个是创建lambda对象，另一个是调用lambda方法。它们可能不太重要。
另请参见http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/以比较不同用例的内部/外部迭代。
void forEach(Consumer<T> v){leftTree.forEach(v);v.accept(rootElem);rightTree.forEach(v);}，这种方法比外部迭代更加优雅，同时你可以自行决定如何最佳同步。 - ratchet freakString.join方法中唯一的注释（好吧，join错误了）是“元素数量不太值得使用Arrays.stream开销”，所以他们使用了一个高级的for循环。 - Tom Hawtin - tackline简而言之: List.stream().forEach() 是最快的。
我觉得我应该添加一下我的迭代基准测试结果。 我采用了非常简单的方法（没有使用基准测试框架），并对5种不同的方法进行了基准测试:
forList.forEach()List.stream().forEach()List.parallelStream().forEachprivate List<Integer> list;
private final int size = 1_000_000;
public MyClass(){
list = new ArrayList<>();
Random rand = new Random();
for (int i = 0; i < size; ++i) {
list.add(rand.nextInt(size * 50));
}
}
private void doIt(Integer i) {
i *= 2; //so it won't get JITed out
}
这个类中的列表应该被迭代，并且每次通过不同的方法对其所有成员应用doIt(Integer i)。
在主类中，我运行测试方法三次以预热JVM。然后我运行测试方法1000次，计算每个迭代方法所需的时间（使用System.nanoTime()）。完成后，我将总和除以1000，得到平均时间作为结果。
例如：
myClass.fored();
myClass.fored();
myClass.fored();
for (int i = 0; i < reps; ++i) {
begin = System.nanoTime();
myClass.fored();
end = System.nanoTime();
nanoSum += end - begin;
}
System.out.println(nanoSum / reps);
我在一台i5四核CPU上运行了这个程序，使用的是Java版本1.8.0_05。
for循环for(int i = 0, l = list.size(); i < l; ++i) {
doIt(list.get(i));
}
执行时间：4.21毫秒
for(Integer i : list) {
doIt(i);
}
execution time: 5.95 ms
List.forEach()list.forEach((i) -> doIt(i));
execution time: 3.11 ms
List.stream().forEach()list.stream().forEach((i) -> doIt(i));
执行时间：2.79毫秒
List.parallelStream().forEachlist.parallelStream().forEach((i) -> doIt(i));
执行时间：3.6毫秒
System.nanoTime()。如果你看了答案，你就会知道它是如何完成的。我认为这并不使它无用，因为这是一个相对的问题。我不关心某种方法做得有多好，我关心它与其他方法相比做得有多好。 - Assaf我感觉需要稍微扩展一下我的评论...
关于范式\风格
这可能是最显著的方面。FP之所以流行，是因为你可以避免副作用而得到的好处。我不会深入探讨从中可以得到什么优缺点，因为这与问题无关。
然而，我会说使用Iterable.forEach进行迭代是受到FP启发的，而且更多地将FP带到了Java中（具有讽刺意味的是，我会说在纯FP中没有太多使用forEach的用途，因为它除了引入副作用外什么都不做）。
最后，我想说这更多是你当前编写的口味、风格和范式的问题。
关于并行性。
从性能角度来看，使用Iterable.forEach比foreach(...)没有明显的好处。
根据官方Iterable.forEach文档：
对Iterable的内容执行给定的操作，在迭代时元素出现的顺序中，直到所有元素都已被处理或操作抛出异常。
...即文档非常清楚，没有隐含的并行性。添加一个将是LSP违规。
现在，Java 8中有“平行集合”承诺，但要使用它们，您需要更明确并注意使用它们（例如，请参见mschenk74的答案）。
顺便说一下：在这种情况下，将使用Stream.forEach，它不能保证实际工作将以并行方式完成（取决于底层集合）。
更新：可能不那么明显，一眼看去有点牵强，但从样式和可读性角度来看，还有另一个方面。
首先-普通的for循环是平淡无奇的。每个人都已经知道了它们。
其次，更重要的是-您可能只想使用具有一行代码的lambda表达式进行Iterable.forEach。如果“body”变得更重-它们往往不太可读。 从这里开始，您有两个选择-使用内部类（yuck）或使用普通的forloop。 当人们看到同一代码库中的相同事物（对集合进行迭代）以各种不同的方式/风格执行时，他们经常感到烦恼，这似乎就是这种情况。
同样，这可能或可能不是一个问题。取决于处理代码的人们。
collection.forEach(MyClass::loopBody); - ratchet freak最不受欢迎的函数之一是forEach，它的一个限制是缺少对检查异常的支持。
可能的解决方法之一是使用普通的for循环来替换终端的forEach：
Stream<String> stream = Stream.of("", "1", "2", "3").filter(s -> !s.isEmpty());
Iterable<String> iterable = stream::iterator;
for (String s : iterable) {
fileWriter.append(s);
}
Here I have created new Class that will override accept class method from Consumer Class, where you can add additional functionility, More than Iteration..!!!!!!
class MyConsumer implements Consumer<Integer>{
@Override
public void accept(Integer o) {
System.out.println("Here you can also add your business logic that will work with Iteration and you can reuse it."+o);
}
}
public class ForEachConsumer {
public static void main(String[] args) {
// Creating simple ArrayList.
ArrayList<Integer> aList = new ArrayList<>();
for(int i=1;i<=10;i++) aList.add(i);
//Calling forEach with customized Iterator.
MyConsumer consumer = new MyConsumer();
aList.forEach(consumer);
// Using Lambda Expression for Consumer. (Functional Interface)
Consumer<Integer> lambda = (Integer o) ->{
System.out.println("Using Lambda Expression to iterate and do something else(BI).. "+o);
};
aList.forEach(lambda);
// Using Anonymous Inner Class.
aList.forEach(new Consumer<Integer>(){
@Override
public void accept(Integer o) {
System.out.println("Calling with Anonymous Inner Class "+o);
}
});
}
}
joins.forEach((join) -> mIrc.join(mSession, join));真的是将for (String join : joins) { mIrc.join(mSession, join); }简化了吗？你增加了标点符号的数量，从9个变成了12个，以隐藏join的类型。实际上，你只是把两个语句放到了一行上。 - Tom Hawtin - tackline