for-eachループとイテレーターのどちらがより効率的ですか？

コレクションをトラバースする最も効率的な方法はどれですか。

List<Integer>  a = new ArrayList<Integer>();
for (Integer integer : a) {
  integer.toString();
}

または

List<Integer>  a = new ArrayList<Integer>();
for (Iterator iterator = a.iterator(); iterator.hasNext();) {
   Integer integer = (Integer) iterator.next();
   integer.toString();
}

これはthis、this、this、またはthisの完全な複製ではありませんが、最後の質問に対する答えの1つが近くなりました。これがだまされない理由は、これらのほとんどがget(i)反復子を使用するのではなく、ループ内で呼び出すループを比較しているためです。

メタで示唆されているように、私はこの質問に対する私の答えを投稿します。

コレクションをさまよい、すべての値を読み取る場合、新しい構文ではイテレーターを水中で使用するだけなので、イテレーターを使用しても新しいforループ構文を使用しても違いはありません。

ただし、ループとは、古い「cスタイル」ループを意味します。

for(int i=0; i<list.size(); i++) {
   Object o = list.get(i);
}

次に、基礎となるデータ構造に応じて、新しいforループ、つまりイテレーターがはるかに効率的になります。これは、一部のデータ構造でget(i)は、ループがO（n ²）操作になるO（n ）操作であるためです。従来のリンクリストは、このようなデータ構造の例です。すべてのイテレータにはnext()、ループをO（n）にするO（1）操作である必要がある基本的な要件があります。

イテレーターが新しいforループ構文によって水中で使用されていることを確認するには、以下の2つのJavaスニペットから生成されたバイトコードを比較します。最初にforループ：

List<Integer>  a = new ArrayList<Integer>();
for (Integer integer : a)
{
  integer.toString();
}
// Byte code
 ALOAD 1
 INVOKEINTERFACE java/util/List.iterator()Ljava/util/Iterator;
 ASTORE 3
 GOTO L2
L3
 ALOAD 3
 INVOKEINTERFACE java/util/Iterator.next()Ljava/lang/Object;
 CHECKCAST java/lang/Integer
 ASTORE 2 
 ALOAD 2
 INVOKEVIRTUAL java/lang/Integer.toString()Ljava/lang/String;
 POP
L2
 ALOAD 3
 INVOKEINTERFACE java/util/Iterator.hasNext()Z
 IFNE L3

次に、イテレータ：

List<Integer>  a = new ArrayList<Integer>();
for (Iterator iterator = a.iterator(); iterator.hasNext();)
{
  Integer integer = (Integer) iterator.next();
  integer.toString();
}
// Bytecode:
 ALOAD 1
 INVOKEINTERFACE java/util/List.iterator()Ljava/util/Iterator;
 ASTORE 2
 GOTO L7
L8
 ALOAD 2
 INVOKEINTERFACE java/util/Iterator.next()Ljava/lang/Object;
 CHECKCAST java/lang/Integer
 ASTORE 3
 ALOAD 3
 INVOKEVIRTUAL java/lang/Integer.toString()Ljava/lang/String;
 POP
L7
 ALOAD 2
 INVOKEINTERFACE java/util/Iterator.hasNext()Z
 IFNE L8

ご覧のとおり、生成されたバイトコードは事実上同一であるため、どちらの形式を使用してもパフォーマンスが低下することはありません。したがって、for-eachループとなるほとんどの人にとって、ボイラープレートコードが少ないため、最も美的に魅力的なループの形式を選択する必要があります。

違いはパフォーマンスではなく、機能にあります。参照を直接使用する場合は、タイプのイテレータを明示的に使用するより強力です（例：List.iterator（）とList.listIterator（）。ほとんどの場合、同じ実装を返します）。ループ内でイテレーターを参照することもできます。これにより、ConcurrentModificationExceptionを取得せずに、コレクションからアイテムを削除するなどの操作を実行できます。

例えば

これはOKです：

Set<Object> set = new HashSet<Object>();
// add some items to the set

Iterator<Object> setIterator = set.iterator();
while(setIterator.hasNext()){
     Object o = setIterator.next();
     if(o meets some condition){
          setIterator.remove();
     }
}

これはそうではありません。同時変更例外がスローされるためです。

Set<Object> set = new HashSet<Object>();
// add some items to the set

for(Object o : set){
     if(o meets some condition){
          set.remove(o);
     }
}

Paul自身の答えを拡張するために、彼はバイトコードがその特定のコンパイラー（おそらくSunのjavac？）で同じであることを示しましたが、異なるコンパイラーが同じバイトコードを生成することは保証されていませんよね？2つの間の実際の違いを確認するには、ソースに直接移動して、Java言語仕様、具体的には14.14.2「enhanced forステートメント」を確認します。

拡張forステートメントはfor、次の形式の基本ステートメントと同等です。

for (I #i = Expression.iterator(); #i.hasNext(); ) {
    VariableModifiers(opt) Type Identifier = #i.next();    
    Statement 
}

言い換えると、JLSは2つが同等であることを要求します。理論的には、バイトコードのわずかな違いを意味する可能性がありますが、実際には、拡張されたforループは次のことを行う必要があります。

• .iterator()メソッドを呼び出す
• 使用する .hasNext()
• ローカル変数を利用可能にする .next()

つまり、言い換えると、すべての実用的な目的のために、バイトコードは同一またはほぼ同一になります。2つの間の有意差をもたらすコンパイラーの実装を想定することは困難です。

foreachボンネットが作成されるiteratorのhasNext（）を呼び出すと、値を取得するには（）の次の呼び出し。パフォーマンスの問題は、RandomomAccessを実装するものを使用している場合にのみ発生します。

for (Iterator<CustomObj> iter = customList.iterator(); iter.hasNext()){
   CustomObj custObj = iter.next();
   ....
}

イテレータベースのループのパフォーマンスの問題は、次の理由によります。

1. リストが空の場合でもオブジェクトを割り当てる（Iterator<CustomObj> iter = customList.iterator();）;
2. iter.hasNext() ループのすべての反復中に、invokeInterface仮想呼び出しがあります（すべてのクラスを通過し、次にジャンプの前にメソッドテーブル検索を実行します）。
3. イテレータの実装は、hasNext()コールフィギュアを値にするために、少なくとも2つのフィールドルックアップを行う必要があります。＃1は現在の数を取得し、＃2は合計数を取得します。
4. bodyループ内には、別のinvokeInterface仮想呼び出しがありiter.next（つまり、すべてのクラスを調べて、ジャンプの前にメソッドテーブルの検索を行います）、フィールドの検索も行う必要があります。＃1はインデックスを取得し、＃2は参照を取得します配列へのオフセットを行う配列（すべての反復で）。

潜在的な最適化はindex iteration、キャッシュサイズルックアップを使用するに切り替えることです。

for(int x = 0, size = customList.size(); x < size; x++){
  CustomObj custObj = customList.get(x);
  ...
}

ここにあります：

1. customList.size()forループの最初の作成時に1つのinvokeInterface仮想メソッドを呼び出してサイズを取得します
2. customList.get(x)ループの本体でのgetメソッド呼び出し。これは配列へのフィールド検索であり、配列へのオフセットを実行できます。

メソッドの呼び出し、フィールド検索のトンを減らしました。これLinkedListは、RandomAccessコレクションobjではない、またはコレクションobjではない何かで実行したくない場合、そうしないと、反復ごとにcustomList.get(x)を走査する必要があるものLinkedListになります。

これは、任意のRandomAccessベースリストコレクションであることがわかっている場合に最適です。

foreachとにかくフードの下でイテレータを使用します。それは実際には単なる構文上の砂糖です。

次のプログラムを検討してください。

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) {
        }
    }
}

レッツは、とそれをコンパイルしjavac Whatever.java、
そして逆アセンブルのバイトコードを読んでmain()、使用しました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

以下のforeachようなプログラムにコンパイルされることがわかります。

• を使用してイテレータを作成します List.iterator()
• If Iterator.hasNext()：Iterator.next()ループを呼び出して続行します

「この役に立たないループがコンパイルされたコードから最適化されないのはなぜですか？リスト項目では何も実行されないことがわかります」：.iterator()副作用のある反復可能コードをコーディングすることは可能です、またはそのため、.hasNext()副作用または意味のある結果をもたらします。

データベースからのスクロール可能なクエリを表すイテラブルが劇的な何かをする.hasNext()（データベースに接続する、または結果セットの最後に到達したためにカーソルを閉じるなど）と簡単に想像できます。

したがって、ループ本体で何も起こらないことを証明できたとしても、反復しても意味のある/結果が何も起こらないことを証明する方がコストがかかります（扱いにくい？）。コンパイラーはこの空のループ本体をプログラムに残さなければなりません。

私たちが期待できる最高のものは、コンパイラの警告です。この空のループ本体について警告javac -Xlint:all Whatever.javaしないのは興味深いことです。IntelliJ IDEAはそうします。確かに、Eclipseコンパイラを使用するようにIntelliJを設定しましたが、それが理由ではないかもしれません。

イテレーターは、コレクションを走査または反復するメソッドを提供するJavaコレクションフレームワークのインターフェースです。

コレクションをトラバースしてその要素を読み取ることが目的である場合、イテレーターとforループはどちらも同じように動作します。

for-each コレクションを反復する方法の1つにすぎません。

例えば：

List<String> messages= new ArrayList<>();

//using for-each loop
for(String msg: messages){
    System.out.println(msg);
}

//using iterator 
Iterator<String> it = messages.iterator();
while(it.hasNext()){
    String msg = it.next();
    System.out.println(msg);
}

また、for-eachループは、反復子インターフェースを実装するオブジェクトでのみ使用できます。

forループとイテレータのケースに戻ります。

コレクションを変更しようとすると、違いが生じます。この場合、フェイルファストプロパティがあるため、イテレータの方が効率的です。すなわち。次の要素を繰り返す前に、基礎となるコレクションの構造に変更がないかチェックします。変更が見つかった場合は、ConcurrentModificationExceptionをスローします。

（注：イテレータのこの機能は、java.utilパッケージのコレクションクラスの場合にのみ適用できます。本質的にフェイルセーフであるため、並行コレクションには適用できません。）

コレクションの操作中は、従来のforループを使用しないでください。私が与える単純な理由は、forループの複雑さはO（sqr（n））のオーダーであり、Iteratorまたはさらに強化されたforループの複雑さは単なるO（n）であることです。だから、それはパフォーマンスの違いを与えます..ちょうど約1000の項目のリストを取り、両方の方法を使用してそれを印刷します。また、実行の時差も出力します。違いがわかります。