Pour chaque vs Itérateur. Qui sera la meilleure option

for-each est sucre syntaxique pour l'utilisation de iterators (approche 2).

Vous pourriez avoir besoin d'utiliser iterators si vous avez besoin de modifier de collecte dans votre boucle. Première approche va jeter l'exception.

for (String i : list) {
    System.out.println(i);
    list.remove(i); //throws exception
} 

Iterator it=list.iterator();
while (it.hasNext()){
    System.out.println(it.next());
    it.remove(); //valid here
}

for-each est une construction de boucle. En interne, il crée un Itérateur et parcourt la Collection. Seul le parti possible de l'aide d'un Itérateur d'objet au-dessus de la for-each construire est que vous pouvez modifier votre collection à l'aide d'Itérateur de méthodes comme .remove(). La modification de la collection sans utiliser l'Itérateur de méthodes lors de l'itération va produire un ConcurrentModificationException.

Réponse Simple: non et Non.

À l'intérieur de l' for-each boucle crée un Iterator pour parcourir la collection.

L'avantage de l'utilisation de la Iterator explicitement, c'est que vous pouvez accéder à la Iterators méthode.

foreach utilise les itérateurs sous le capot de toute façon. Il est vraiment juste sucre syntaxique.

Considérons le programme suivant:

import java.util.List;
import java.util.ArrayList;

public class Whatever {
    private final List<Integer> list = new ArrayList<>();
    public void main() {
        for(Integer i : list) {
        }
    }
}

Nous allons compiler avec javac Whatever.java,

Et de lire le démonté le bytecode de main(), à l'aide de javap -c Whatever:

public void main();
  Code:
     0: aload_0
     1: getfield      #4                  //Field list:Ljava/util/List;
     4: invokeinterface #5,  1            //InterfaceMethod java/util/List.iterator:()Ljava/util/Iterator;
     9: astore_1
    10: aload_1
    11: invokeinterface #6,  1            //InterfaceMethod java/util/Iterator.hasNext:()Z
    16: ifeq          32
    19: aload_1
    20: invokeinterface #7,  1            //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
    25: checkcast     #8                  //class java/lang/Integer
    28: astore_2
    29: goto          10
    32: return

Nous pouvons voir que foreach compile vers le bas pour un programme qui:

• Crée un itérateur à l'aide de List.iterator()
• Si Iterator.hasNext(): invoque Iterator.next() et continue de la boucle

Comme "pourquoi n'est-il pas inutile de boucle optimiser de le code compilé? nous pouvons voir qu'il ne fait rien à l'élément de liste": eh bien, il est possible pour vous de votre code itératif tel que .iterator() a des effets secondaires, ou de sorte que .hasNext() a des effets secondaires ou des conséquences significatives.

Vous pouvez facilement imaginer qu'un objet iterable représentant un défilement de requête à partir d'une base de données peut faire quelque chose de spectaculaire sur les .hasNext() (comme communiquant avec la base de données, ou la fermeture d'un curseur parce que vous avez atteint la fin du jeu de résultats).

Ainsi, même si l'on peut prouver que rien ne se passe dans le corps de la boucle... c'est plus cher (insolubles?) pour prouver que rien de significatif/indirects qui se passe lorsque nous itération. Le compilateur a partir de ce vide corps de boucle dans le programme.

Le meilleur que nous pouvions espérer serait un compilateur avertissement. Il est intéressant de noter que javac -Xlint:all Whatever.java ne pas nous avertir de ce vide corps de boucle. IntelliJ IDEA ne bien que. Certes, j'ai configuré l'Ide d'utiliser Eclipse Compilateur, mais qui ne peuvent pas être la raison du pourquoi.