Java 8 Itératif.forEach() vs boucle foreach

La meilleure pratique consiste à utiliser for-each. En plus de violer le Keep It Simple, Stupid principe, le principe d'un nouveau genre forEach() a au moins les insuffisances suivantes:

• Ne pouvez pas utiliser des variables final. Ainsi, le code suivant ne peut pas être transformé en un forEach lambda:

  Object prev = null;
  for(Object curr : list)
  {
      if( prev != null )
          foo(prev, curr);
      prev = curr;
  }

• Ne peut pas gérer checked exceptions. Les Lambdas ne sont pas réellement interdit de jeter checked exceptions, mais les interfaces fonctionnelles comme Consumer ne pas déclarer tout. Par conséquent, tout code qui jette vérifié les exceptions doivent envelopper dans try-catch ou Throwables.propagate(). Mais même si vous le faites, il n'est pas toujours clairement ce qui se passe à la levée d'une exception. Il pourrait être avalé quelque part dans les entrailles de forEach()

• Limité le contrôle du flux de. Un return dans un lambda est égal à un continue dans un chacun, mais il n'y a pas l'équivalent d'un break. Il est aussi difficile de faire des choses comme valeurs de retour, court-circuit, ou définir des indicateurs (ce qui aurait atténué les choses un peu, si ce n'était pas une violation de la pas de non-final variables la règle). "Ce n'est pas seulement une optimisation, mais c'est essentiel si l'on considère que certaines séquences (comme la lecture des lignes dans un fichier) peut avoir des effets secondaires, ou vous pouvez avoir une suite infinie."

• Peut exécuter en parallèle, qui est un horrible, horrible chose pour tous, mais les 0,1% de votre code qui doit être optimisé. Tout code parallèle doit être pensé (même si elle n'utilise pas les serrures, les volatiles, et d'autres particulièrement désagréable aspects de la traditionnelle multi-thread d'exécution). Aucun bug va être difficile à trouver.

• Pourrait nuire à la performance d', parce que l'équipe ne peut pas optimiser forEach()+lambda dans la même mesure que la plaine de boucles, surtout maintenant que les lambdas sont nouveaux. Par "optimisation" je ne veux pas les frais généraux de l'appel à lambdas (qui est petite), mais à la plus sophistiquée d'analyse et de transformation de modernes compilateur JIT exécute sur l'exécution de code.

• Si vous avez besoin de parallélisme, il est probablement beaucoup plus rapide et pas beaucoup plus difficile à utiliser un ExecutorService. Les ruisseaux sont à la fois automagical (lire: ne sais pas beaucoup au sujet de votre problème) et utiliser spécialisée (lire: inefficace pour le cas général) de parallélisation de la stratégie (fork-join de décomposition récursive).

• Rend le débogage plus de confusion, en raison de la imbriquée à l'appel de la hiérarchie et, à dieu ne plaise, l'exécution en parallèle. Le débogueur peut avoir des problèmes d'affichage de variables à partir de l'environnement de code, et des choses comme par étape-ne peut pas fonctionner comme prévu.

• Flux en général, sont plus difficiles à code, lire, et de débogage. En fait, cela est vrai de complexe "couramment" Api en général. La combinaison de complexe unique déclarations, l'utilisation excessive de médicaments génériques, et de l'absence de variables intermédiaires, concourent à produire de la confusion des messages d'erreur et de frustration pour le débogage. Au lieu de "cette méthode n'a pas une surcharge pour le type X", vous obtenez un message d'erreur plus proche de "quelque part, vous foiré les types, mais nous ne savons pas où, ni comment." De même, vous ne pouvez pas parcourir et examiner les choses dans un débogueur, aussi facilement que lorsque le code est divisé en plusieurs états, et les valeurs intermédiaires sont enregistrées dans des variables. Enfin, la lecture du code et de comprendre les types et le comportement à chaque étape de l'exécution peut être non négligeable.

• Colle dehors comme un pouce endolori. Le langage Java a déjà le pour-chaque instruction. Pourquoi le remplacer par un appel de fonction? Pourquoi encourager les cacher effets secondaires quelque part dans les expressions? Pourquoi encourager les encombrants one-liners? Mélanger régulièrement pour-chaque et de nouvelles forEach bon gré mal gré est mauvais style. Le Code doit parler dans les expressions idiomatiques (modèles qui sont faciles à comprendre en raison de leur répétition), et le moins idiomes sont utilisés le plus clair, le code est et moins de temps est consacré à choisir quel idiome à utiliser (un grand moment de drain pour les perfectionnistes comme moi!).

Comme vous pouvez le voir, je ne suis pas un grand fan de la boucle forEach (), sauf dans les cas où cela a du sens.

Particulièrement choquant pour moi est le fait que Stream ne pas mettre en œuvre Iterable (malgré le fait d'avoir de la méthode iterator) et ne peut être utilisé dans un for-each, seulement avec un forEach(). Je recommande casting les cours d'eau en Iterables avec (Iterable<T>)stream::iterator. Une meilleure alternative est d'utiliser StreamEx qui fixe un certain nombre de Flux API problèmes, y compris la mise en œuvre de Iterable.

Cela dit, forEach() est utile pour:

• Atomiquement de parcourir un synchronisé liste. Avant cela, une liste générée avec Collections.synchronizedList() a été atomique à l'égard des choses comme obtenir ou de définir, mais n'était pas thread-safe lors de l'itération.

• L'exécution en parallèle (en utilisant le courant parallèle). Cela vous permet d'économiser quelques lignes de code vs à l'aide d'un ExecutorService, si votre problème correspond à la performance des hypothèses construites dans les cours d'eau et Spliterators.

• Des conteneurs spécifiques qui, comme la synchronisation de liste, profiter d'être dans le contrôle de l'itération (même si cela est en grande partie théorique, les gens ne peuvent proposer d'autres exemples)

• L'appel d'une fonction unique plus proprement en utilisant forEach() et une méthode de référence argument (c'est à dire, list.forEach (obj::someMethod)). Cependant, gardez à l'esprit les points sur checked exceptions, de plus en plus difficile de débogage, et de réduire le nombre d'expressions que vous utilisez lors de l'écriture de code.

Articles que j'ai utilisé pour référence:

• Tout à propos de Java 8
• Itération Intérieur et à l'extérieur (comme l'a souligné une autre affiche)

EDIT: Ressemble à certaines de ses propositions pour les lambdas (comme http://www.javac.info/closures-v06a.html) résolu certains des problèmes que j'ai mentionnés (tout en ajoutant leurs propres complications, bien sûr).

Lors de la lecture de cette question, on peut avoir l'impression, que Iterable#forEach en combinaison avec les expressions lambda est un raccourci/remplacement pour l'écriture traditionnelle boucle for-each. Ce n'est tout simplement pas vrai. Ce code à partir de l'OP:

joins.forEach(join -> mIrc.join(mSession, join));

est pas conçu comme un raccourci pour l'écriture

for (String join : joins) {
    mIrc.join(mSession, join);
}

et devrait certainement pas être utilisé de cette façon. Au lieu de cela, il est conçu comme un raccourci (même si c'est pas exactement le même) pour l'écriture

joins.forEach(new Consumer<T>() {
    @Override
    public void accept(T join) {
        mIrc.join(mSession, join);
    }
});

Et c'est comme un remplacement pour la suite de Java 7 code:

final Consumer<T> c = new Consumer<T>() {
    @Override
    public void accept(T join) {
        mIrc.join(mSession, join);
    }
};
for (T t : joins) {
    c.accept(t);
}

Remplacer le corps de la boucle, avec une interface fonctionnelle, comme dans les exemples ci-dessus, rend votre code plus explicite: "Vous dites que (1) le corps de la boucle n'affecte pas le code environnant et le contrôle de flux, et (2) le corps de la boucle peut être remplacée par une autre implémentation de la fonction, sans affecter le code environnant. N'étant pas en mesure d'accéder non les variables final de l'extérieur de la portée n'est pas un déficit de fonctions/lambdas, c'est un fonction qui distingue la sémantique de Iterable#forEach de la sémantique de la traditionnelle boucle for-each. Une fois que l'on s'habitue à la syntaxe de Iterable#forEach, il rend le code plus lisible, parce que vous obtenez immédiatement cette information supplémentaire au sujet du code.

Traditionnelles boucles for-each va certainement rester bonnes pratiques (pour éviter le terme galvaudé "les meilleures pratiques") en Java. Mais cela ne veut pas dire, que Iterable#forEach devrait être considéré comme une mauvaise pratique ou de mauvais style. Il est toujours de bonne pratique, à utiliser le bon outil pour faire le travail, et cela inclut le mélange traditionnel pour chaque boucles avec Iterable#forEach, où il fait sens.

Depuis les inconvénients de la Iterable#forEach il a déjà été question dans ce fil, voici quelques raisons pour lesquelles vous pourriez probablement vouloir utiliser Iterable#forEach:

• Pour rendre votre code plus explicite: Comme décrit ci-dessus, Iterable#forEach peut de rendre votre code plus explicite et lisible dans certaines situations.

• Pour rendre votre code plus extensible et facile à entretenir: à l'Aide d'une fonction comme le corps d'une boucle permet de remplacer cette fonction avec différentes implémentations (voir Modèle De Stratégie). Vous pourriez par exemple facilement remplacer l'expression lambda avec un appel de méthode, qui peuvent être remplacées par des sous-classes:

  joins.forEach(getJoinStrategy());

  Alors vous pourriez fournir des stratégies par défaut à l'aide d'un enum, qui implémente l'interface fonctionnelle. Non seulement cela rend votre code plus extensible, il augmente également la facilité de maintenance, car il dissocie la boucle de la mise en œuvre de la boucle de la déclaration.

• Pour rendre votre code plus debuggable: Séparant la boucle de la mise en œuvre de la déclaration peut également faciliter le débogage plus facile, parce que vous pourriez avoir spécialisée de débogage de la mise en œuvre, qui permet d'afficher les messages de débogage, sans le besoin d'encombrer votre code principal avec if(DEBUG)System.out.println(). Le débogage de la mise en œuvre pourrait, par exemple, être un délégué, que orne de la fonction réelle mise en œuvre.

• Pour optimiser la performance de code critique: Contrairement à certaines affirmations contenues dans ce fil, Iterable#forEach ne déjà fournir de meilleures performances que les méthodes classiques pour chaque boucle, au moins lors de l'utilisation de liste de tableaux et de course Hotspot "client" de mode. Bien que ce gain de performance est faible et négligeable pour la plupart des cas, il existe des situations où cette performance supplémentaire peut faire la différence. E. g. bibliothèque responsables aurez certainement envie d'évaluer, si certains de leurs existant boucle implémentations devraient être remplacés par Iterable#forEach.

  À propos des faits, j'ai fait quelques micro-benchmarks avec Étrier. Voici le code de test (dernière Étrier de git est nécessaire):

  @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++;
  }
  }
  }
  }

  Et voici les résultats:

  • Les résultats pour le client
  • Résultats pour serveur

  Lors de l'exécution avec le "client", Iterable#forEach surpasse le traditionnel pour une boucle sur une liste de tableaux, mais il est encore plus lent que directement à parcourir un tableau. Lors de l'exécution avec le "serveur", la performance de l'ensemble des approches est la même.

• De fournir un support optionnel pour l'exécution en parallèle: Il a déjà été dit ici, que la possibilité d'exécuter l'interface fonctionnelle de Iterable#forEach en parallèle à l'aide de flux, est certainement un aspect important. Depuis Collection#parallelStream() ne garantit pas, que la boucle est exécutée en parallèle, on doit considérer cela comme un facultatif fonctionnalité. Par itération sur votre liste avec list.parallelStream().forEach(...);, vous avez explicitement le dire: Cette boucle prend en charge l'exécution en parallèle, mais il ne dépend pas d'elle. Encore une fois, c'est une fonction et non d'un déficit de!

  En déplaçant la décision pour l'exécution en parallèle à l'écart de votre boucle de mise en œuvre, vous permettez à l'option d'optimisation de votre code, sans affecter le code lui-même, ce qui est une bonne chose. Aussi, si le défaut courant parallèle de la mise en œuvre ne répondent pas à vos besoins, personne ne vous empêche de fournir votre propre mise en œuvre. Vous pourriez par exemple offrir une collection optimisée en fonction du sous-jacent système d'exploitation, la taille de la collection, sur le nombre de cœurs, et sur certains paramètres de préférence:

  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();
  }
  }
  }

  La bonne chose ici est que votre boucle de mise en œuvre n'a pas besoin de connaître ou de se soucier de ces détails.

TL;DR: List.stream().forEach() a été le plus rapide.

J'ai senti que je dois ajouter mes résultats d'analyse comparative de l'itération.
J'ai pris une approche très simple (pas d'analyse comparative des cadres) et comparées 5 méthodes différentes:

1. classique for
2. classique foreach
3. List.forEach()
4. List.stream().forEach()
5. List.parallelStream().forEach

la procédure de test et les paramètres

private 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
}

La liste dans cette catégorie doivent être itéré et d'avoir quelques doIt(Integer i) appliqué à tous les membres, à chaque époque, par une méthode différente.
dans la classe Principale-je exécuter la méthode éprouvée trois fois pour se réchauffer de la JVM. Je puis exécutez le test de la méthode de 1000 fois en additionnant le temps qu'il faut pour chaque itération de la méthode (à l'aide de System.nanoTime()). Après cela est fait, je diviser cette somme par 1000 et voilà le résultat, la moyenne du temps.
exemple:

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);

J'ai couru ce sur un i5 4 core CPU, avec la version java 1.8.0_05

classique for

for(int i = 0, l = list.size(); i < l; ++i) {
doIt(list.get(i));
}

temps d'exécution: 4.21 ms

classique foreach

for(Integer i : list) {
doIt(i);
}

temps d'exécution: 5.95 ms

List.forEach()

list.forEach((i) -> doIt(i));

temps d'exécution: 3.11 ms

List.stream().forEach()

list.stream().forEach((i) -> doIt(i));

temps d'exécution: 2.79 ms

List.parallelStream().forEach

list.parallelStream().forEach((i) -> doIt(i));

temps d'exécution: 3.6 ms

L'un des plus upleasing fonctionnelle forEach's limites, c'est le manque de checked exceptions support.

Un solution de contournement possible est de remplacer le terminal forEach par le bon vieux boucle 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);
}

Voici une liste des questions les plus appréciées avec d'autres solutions de contournement sur vérifié la gestion des exceptions dans les lambdas et des ruisseaux:

Java 8 fonction Lambda qui lève une exception?

Java 8: Lambda-Flux, Filtre par la Méthode à l'Exception

Comment puis-je jeter CHECKED exceptions à l'intérieur de Java 8 flux?

Java 8: Obligatoire vérifié la gestion des exceptions dans les expressions lambda. Pourquoi obligatoire, pas une option?