Що є більш ефективним, для кожного циклу чи ітератором?

Який найефективніший спосіб перемістити колекцію?

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

Зауважте, що це не точний дублікат цього , цього , цього чи цього , хоча одна з відповідей на останнє питання наближається. Причина того, що це не дуп, полягає в тому, що більшість із них порівнюють петлі, де ви викликаєте get(i)всередині циклу, а не використовуйте ітератор.

Як було запропоновано на Meta, я опублікую свою відповідь на це питання.

Якщо ви просто блукаєте над колекцією, щоб прочитати всі значення, то різниці між використанням ітератора чи новим для синтаксису циклу немає, оскільки новий синтаксис просто використовує ітератор під водою.

Якщо ви маєте на увазі під циклом старий цикл "c-style":

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

Тоді новий цикл або ітератор можуть бути набагато ефективнішими, залежно від основної структури даних. Причиною цього є те, що для деяких структур даних get(i)- це операція O (n), яка робить цикл операцією O (n ² ). Традиційний зв'язаний список є прикладом такої структури даних. Основна вимога до всіх ітераторів є next()операція O (1), що робить цикл O (n).

Щоб переконатися, що ітератор використовується під водою новим для синтаксису циклу, порівняйте згенеровані байт-коди з наступних двох фрагментів 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

Як бачимо, згенерований байт-код фактично ідентичний, тому за використання жодної форми не передбачено покарання за ефективність. Тому вам слід обрати форму петлі, яка найбільш естетично вам подобається, для більшості людей, які будуть циклами для кожного циклу, оскільки в них менше кодового коду.

Різниця не в продуктивності, а в можливостях. При прямому використанні посилання у вас є більше повноважень над явним використанням типу ітератора (наприклад, List.iterator () проти List.listIterator (), хоча в більшості випадків вони повертають ту саму реалізацію). Ви також маєте можливість посилатися на Ітератор у своєму циклі. Це дозволяє робити такі речі, як видалення елементів із колекції, не отримуючи ConcurrentModificationException.

напр

Це нормально:

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

Щоб розширити власну відповідь Поля, він продемонстрував, що байт-код однаковий для цього конкретного компілятора (імовірно, Sun javac?), Але різні компілятори не гарантовано генерують один і той же байт-код, правда? Щоб побачити, яка фактична різниця між ними, давайте перейдемо безпосередньо до джерела та перевіримо специфікацію мови Java, зокрема 14.14.2, "Розширений для оператора" :

Розширений forвислів еквівалентний базовому forвикладу форми:

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

Іншими словами, JLS вимагає, щоб вони були рівнозначними. Теоретично це може означати граничні відмінності в байт-коді, але насправді посилений цикл вимагає:

• Викликати .iterator()метод
• Використовуйте .hasNext()
• Зробіть доступною локальну змінну через .next()

Отже, іншими словами, для всіх практичних цілей байт-код буде ідентичним, або майже ідентичним. Важко передбачити будь-яку реалізацію компілятора, яка б призвела до суттєвої різниці між ними.

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()цифра виклику отримала значення: №1 отримає поточний підрахунок та №2 отримає загальний підрахунок
4. всередині циклу тіла є ще один віртуальний виклик 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 для отримання розміру
2. виклик методу get customList.get(x)під час тіла для циклу, який є полем пошуку для масиву, а потім може зробити зсув у масив

Ми зменшили тонну викликів методів, пошук у полі. Цього ви не хочете робити з LinkedListчи з чимось, що не є RandomAccessоб'єктом колекції, інакше 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()
• Якщо Iterator.hasNext(): викликає Iterator.next()і продовжує цикл

Що стосується "чому цей марний цикл не оптимізується зі складеного коду? Ми можемо побачити, що він нічого не робить із елементом списку": ну, ви можете кодувати свій ітерабельний такий, що .iterator()має побічні ефекти або так, що .hasNext()має побічні ефекти або значущі наслідки.

Ви можете легко уявити, що ітерабельний варіант, який представляє запит, який можна прокручувати з бази даних, може зробити щось драматичне .hasNext()(наприклад, звернення до бази даних або закриття курсору, оскільки ви досягли кінця набору результатів).

Отже, навіть якщо ми можемо довести, що в тілі циклу нічого не відбувається ... дорожче (незрозуміле?) Довести, що нічого важливого / наслідкового не відбувається, коли ми повторюємо. Компілятор повинен залишити це порожнє тіло циклу в програмі.

Найкраще , що ми могли сподіватися б компілятор попередження . Цікаво , що javac -Xlint:all Whatever.javaце НЕ попереджає нас про це порожньому тілі циклу. IntelliJ IDEA робить це. Справді, я налаштував IntelliJ на використання компілятора Eclipse, але це може бути не причиною.

Iterator - це інтерфейс в рамках Java Collections, який забезпечує методи переходу або повторення по колекції.

Ітератор, і цикл діють аналогічно, коли ваш мотив - просто перейти колекцію, щоб прочитати її елементи.

for-each це лише один із способів ітерації над Колекцією.

Наприклад:

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

І для-кожного циклу можна користуватися лише на об'єктах, що реалізують інтерфейс ітератора.

Тепер повернемося до справи для циклу та ітератора.

Різниця виникає при спробі змінити колекцію. У цьому випадку ітератор є більш ефективним через свою невдалу властивість . тобто. він перевіряє будь-які зміни в структурі базової колекції перед ітерацією над наступним елементом. Якщо знайдеться якісь модифікації, це викине ConcurrentModificationException .

(Примітка. Ця функціональність ітератора застосована лише у випадках, коли класи колекцій в пакеті java.util. Він не застосовується для одночасних колекцій, оскільки вони за своєю природою не захищені)

Ми повинні уникати використання традиційних для циклу під час роботи з колекціями. Проста причина, яку я надам, полягає в тому, що складність для циклу має порядок O (sqr (n)), а складність Iterator або навіть посилена для циклу - це просто O (n). Таким чином, це дає різницю у виконанні. Просто візьміть список з 1000 предметів і роздрукуйте його обома способами. а також надрукувати різницю у часі для виконання. Ви бачите різницю.