Java 8 Iterable.forEach () vs foreach loop

Quale delle seguenti è la migliore pratica in Java 8?

Java 8:

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

Java 7:

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

Ho un sacco di loop che potrebbero essere "semplificati" con lambdas, ma c'è davvero qualche vantaggio nell'usarli? Migliorerebbe le loro prestazioni e leggibilità?

MODIFICARE

Estenderò anche questa domanda a metodi più lunghi. So che non è possibile ripristinare o interrompere la funzione genitore da una lambda e questo dovrebbe essere preso in considerazione anche quando si confrontano, ma c'è qualcos'altro da considerare?

La migliore pratica è usare for-each. Oltre a violare il principio Keep It Simple, Stupid , il nuovo zangolato forEach()presenta almeno le seguenti carenze:

• Impossibile utilizzare le variabili non finali . Quindi, codice come il seguente non può essere trasformato in un forda Ogni lambda:

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

• Impossibile gestire le eccezioni verificate . A Lambdas non è effettivamente proibito lanciare eccezioni verificate, ma le interfacce funzionali comuni come Consumernon ne dichiarano alcuna. Pertanto, qualsiasi codice che genera eccezioni controllate deve includerli in try-catcho Throwables.propagate(). Ma anche se lo fai, non è sempre chiaro cosa succede all'eccezione generata. Potrebbe essere ingoiato da qualche parte nelle viscere diforEach()

• Controllo di flusso limitato . A returnin a lambda è uguale a a continuein a per-ciascuno, ma non esiste un equivalente di a break. È anche difficile fare cose come valori di ritorno, corto circuito o impostare flag (che avrebbe alleviato un po 'le cose, se non fosse stata una violazione della regola delle variabili non finali ). "Questa non è solo un'ottimizzazione, ma fondamentale quando si considera che alcune sequenze (come leggere le righe in un file) possono avere effetti collaterali o si può avere una sequenza infinita."

• Potrebbe essere eseguito in parallelo , che è una cosa orribile, orribile per tutti tranne lo 0,1% del codice che deve essere ottimizzato. Qualsiasi codice parallelo deve essere considerato attraverso (anche se non utilizza blocchi, volatili e altri aspetti particolarmente cattivi dell'esecuzione multi-thread tradizionale). Qualsiasi bug sarà difficile da trovare.

• Potrebbe danneggiare le prestazioni , perché JIT non può ottimizzare forEach () + lambda nella stessa misura dei semplici loop, soprattutto ora che i lambda sono nuovi. Per "ottimizzazione" non intendo il sovraccarico di chiamare lambdas (che è piccolo), ma per la sofisticata analisi e trasformazione che il moderno compilatore JIT esegue sul codice in esecuzione.

• Se hai bisogno di parallelismo, è probabilmente molto più veloce e non molto più difficile usare un ExecutorService . I flussi sono sia automagici (leggi: non sanno molto del tuo problema) sia usano una strategia specializzata (leggi: inefficiente per il caso generale) ( decomposizione ricorsiva fork-join ).

• Rende il debug più confuso , a causa della gerarchia di chiamate nidificate e, a Dio non voglia, esecuzione parallela. Il debugger potrebbe avere problemi nella visualizzazione delle variabili dal codice circostante e cose come il passaggio rapido potrebbero non funzionare come previsto.

• Gli stream in generale sono più difficili da codificare, leggere e debug . In realtà, questo è vero per le API complesse " fluenti " in generale. La combinazione di singole istruzioni complesse, un uso intenso di generici e la mancanza di variabili intermedie cospirano per produrre messaggi di errore confusi e debug frustrato. Invece di "questo metodo non ha un sovraccarico per il tipo X" viene visualizzato un messaggio di errore più vicino a "da qualche parte hai incasinato i tipi, ma non sappiamo dove o come". Allo stesso modo, non è possibile scorrere ed esaminare le cose in un debugger con la stessa facilità di quando il codice viene suddiviso in più istruzioni e i valori intermedi vengono salvati in variabili. Infine, leggere il codice e comprendere i tipi e il comportamento in ogni fase dell'esecuzione potrebbe non essere banale.

• Sporge come un pollice dolorante . Il linguaggio Java ha già l'istruzione for-each. Perché sostituirlo con una chiamata di funzione? Perché incoraggiare a nascondere effetti collaterali da qualche parte nelle espressioni? Perché incoraggiare un liner monotono? Mescolare regolarmente per ognuno e nuovo per ogni volente o nolente è un cattivo stile. Il codice dovrebbe parlare in idiomi (schemi che sono rapidi da comprendere a causa della loro ripetizione), e meno idiomi vengono usati più chiaro è il codice e meno tempo viene speso a decidere quale idioma usare (un grande dispendio di tempo per i perfezionisti come me! ).

Come puoi vedere, non sono un grande fan di forEach () tranne nei casi in cui ha senso.

Particolarmente offensivo per me è il fatto che Streamnon si attua Iterable(nonostante abbia effettivamente un metodo iterator) e non può essere utilizzato in un for-each, solo con un forEach (). Consiglio di trasmettere Stream in Iterables con (Iterable<T>)stream::iterator. Un'alternativa migliore è utilizzare StreamEx che risolve una serie di problemi relativi all'API Stream, inclusa l'implementazione Iterable.

Detto questo, forEach()è utile per quanto segue:

• Iterando atomicamente su un elenco sincronizzato . Prima di questo, un elenco generato con Collections.synchronizedList()era atomico rispetto a cose come get o set, ma non era thread-safe durante l'iterazione.

• Esecuzione parallela (utilizzando un flusso parallelo appropriato) . Ciò consente di risparmiare alcune righe di codice rispetto all'utilizzo di un ExecutorService, se il problema corrisponde alle ipotesi sulle prestazioni integrate in Stream e Spliterator.

• Contenitori specifici che , come l'elenco sincronizzato, traggono vantaggio dal controllo dell'iterazione (sebbene ciò sia in gran parte teorico a meno che le persone non possano far apparire altri esempi)

• Chiamare una singola funzione in modo più pulito utilizzando forEach()e un argomento di riferimento del metodo (ovvero, list.forEach (obj::someMethod)). Tuttavia, tenere presente i punti relativi alle eccezioni verificate, al debug più difficile e alla riduzione del numero di idiomi utilizzati durante la scrittura del codice.

Articoli che ho usato come riferimento:

• Tutto su Java 8
• Iteration Inside and Out (come sottolineato da un altro poster)

EDIT: Sembra che alcune delle proposte originali di lambdas (come http://www.javac.info/closures-v06a.html ) abbiano risolto alcuni dei problemi che ho citato (aggiungendo ovviamente le loro complicazioni).

Il vantaggio viene preso in considerazione quando le operazioni possono essere eseguite in parallelo. (Vedi http://java.dzone.com/articles/devoxx-2012-java-8-lambda-and - la sezione sull'iterazione interna ed esterna)

• Il vantaggio principale dal mio punto di vista è che l'implementazione di ciò che deve essere fatto all'interno del loop può essere definita senza dover decidere se verrà eseguita in parallelo o in sequenza

• Se vuoi che il tuo ciclo sia eseguito in parallelo, potresti semplicemente scrivere

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

  Dovrai scrivere del codice aggiuntivo per la gestione dei thread, ecc.

Nota: per la mia risposta ho assunto l'adesione all'implementazione java.util.Streamdell'interfaccia. Se si unisce implementa solo l' java.util.Iterableinterfaccia di questo non è più vero.

Leggendo questa domanda si può avere l'impressione che, Iterable#forEachin combinazione con le espressioni lambda, sia una scorciatoia / sostituzione per scrivere un ciclo tradizionale per ogni. Questo semplicemente non è vero. Questo codice dall'OP:

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

non è inteso come scorciatoia per la scrittura

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

e non dovrebbe certamente essere usato in questo modo. Invece è inteso come un collegamento (anche se è non esattamente lo stesso) per la scrittura

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

Ed è in sostituzione del seguente codice Java 7:

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

Sostituire il corpo di un ciclo con un'interfaccia funzionale, come negli esempi sopra, rende il codice più esplicito: stai dicendo che (1) il corpo del ciclo non influenza il codice circostante e il flusso di controllo e (2) il il corpo del loop può essere sostituito con una diversa implementazione della funzione, senza influire sul codice circostante. Non essere in grado di accedere a variabili non finali dell'ambito esterno non è un deficit di funzioni / lambda, è una caratteristica che distingue la semantica Iterable#forEachdalla semantica di un ciclo tradizionale per ogni. Una volta che ci si abitua alla sintassi di Iterable#forEach, rende il codice più leggibile, poiché si ottengono immediatamente queste informazioni aggiuntive sul codice.

I loop tradizionali per ogni rimarranno sicuramente buone pratiche (per evitare il termine abusato " best practice ") in Java. Ma questo non significa che Iterable#forEachdovrebbe essere considerata cattiva pratica o cattivo stile. È sempre una buona pratica usare lo strumento giusto per fare il lavoro, e ciò include la miscelazione di loop tradizionali per ciascuno di essi Iterable#forEach, dove ha senso.

Dato che gli aspetti negativi di Iterable#forEachsono già stati discussi in questo thread, ecco alcuni motivi, per cui potresti voler usare Iterable#forEach:

• Per rendere il codice più esplicito: come descritto sopra, Iterable#forEach può rendere il codice più esplicito e leggibile in alcune situazioni.

• Per rendere il tuo codice più estensibile e gestibile: L' uso di una funzione come corpo di un ciclo ti consente di sostituire questa funzione con diverse implementazioni (vedi Pattern di strategia ). Ad esempio, è possibile sostituire facilmente l'espressione lambda con una chiamata al metodo, che può essere sovrascritta da sottoclassi:

  joins.forEach(getJoinStrategy());

  Quindi è possibile fornire strategie predefinite utilizzando un enum, che implementa l'interfaccia funzionale. Ciò non solo rende il tuo codice più estensibile, ma aumenta anche la manutenibilità perché disaccoppia l'implementazione del ciclo dalla dichiarazione del ciclo.

• Per rendere il tuo codice più debuggabile: separare l'implementazione del ciclo dalla dichiarazione può anche rendere più facile il debug, perché potresti avere un'implementazione di debug specializzata, che stampa i messaggi di debug, senza la necessità di ingombrare il tuo codice principale if(DEBUG)System.out.println(). L'implementazione del debug potrebbe essere ad esempio un delegato , che decora l'implementazione della funzione effettiva.

• Per ottimizzare il codice critico per le prestazioni: Contrariamente ad alcune delle asserzioni in questo thread, Iterable#forEach fornisce già prestazioni migliori rispetto a un ciclo tradizionale per ogni, almeno quando si utilizza ArrayList e si esegue Hotspot in modalità "-client". Mentre questo aumento delle prestazioni è piccolo e trascurabile per la maggior parte dei casi d'uso, ci sono situazioni in cui queste prestazioni extra possono fare la differenza. Ad esempio, i manutentori delle librerie vorranno sicuramente valutare se alcune delle loro implementazioni di loop esistenti debbano essere sostituite con Iterable#forEach.

  A sostegno di questa affermazione con i fatti, ho fatto alcuni micro-benchmark con Caliper . Ecco il codice di test (è necessario l'ultimo Caliper di Git):

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

  E qui ci sono i risultati:

  • Risultati per -client
  • Risultati per -server

  Quando viene eseguito con "-client", Iterable#forEachsupera il tradizionale ciclo per un ArrayList, ma è ancora più lento rispetto all'iterazione diretta su un array. Quando si esegue con "-server", le prestazioni di tutti gli approcci sono più o meno le stesse.

• Per fornire supporto opzionale per l'esecuzione parallela: qui è già stato detto, che la possibilità di eseguire l'interfaccia funzionale Iterable#forEachin parallelo usando flussi , è certamente un aspetto importante. Poiché Collection#parallelStream()non garantisce che il ciclo sia effettivamente eseguito in parallelo, è necessario considerare questa funzione opzionale . Esaminando l'elenco con list.parallelStream().forEach(...);, si dice esplicitamente: questo ciclo supporta l' esecuzione parallela, ma non dipende da esso. Ancora una volta, questa è una caratteristica e non un deficit!

  Allontanando la decisione per l'esecuzione parallela dall'implementazione del ciclo effettivo, consenti l'ottimizzazione facoltativa del codice, senza influire sul codice stesso, il che è positivo. Inoltre, se l'implementazione del flusso parallelo predefinito non soddisfa le tue esigenze, nessuno ti impedisce di fornire la tua implementazione. Ad esempio, è possibile fornire una raccolta ottimizzata in base al sistema operativo sottostante, alla dimensione della raccolta, al numero di core e ad alcune impostazioni delle preferenze:

  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 cosa bella qui è che l'implementazione del tuo loop non ha bisogno di conoscere o preoccuparsi di questi dettagli.

forEach()può essere implementato per essere più veloce di per ogni ciclo, perché l'iterabile conosce il modo migliore per iterare i suoi elementi, al contrario del modo iteratore standard. Quindi la differenza è loop internamente o loop esternamente.

Ad esempio ArrayList.forEach(action)può essere semplicemente implementato come

for(int i=0; i<size; i++)
    action.accept(elements[i])

al contrario del ciclo for-each che richiede molte impalcature

Iterator iter = list.iterator();
while(iter.hasNext())
    Object next = iter.next();
    do something with `next`

Tuttavia, dobbiamo anche tenere conto di due costi generali usando forEach(), uno sta creando l'oggetto lambda, l'altro sta invocando il metodo lambda. Probabilmente non sono significativi.

vedere anche http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/ per il confronto di iterazioni interne / esterne per diversi casi d'uso.

TL; DR : è List.stream().forEach()stato il più veloce.

Ho sentito che avrei dovuto aggiungere i miei risultati dall'iterazione di benchmarking. Ho adottato un approccio molto semplice (nessun framework di benchmarking) e ho confrontato 5 diversi metodi:

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

la procedura di prova e i parametri

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
}

L'elenco in questa classe deve essere ripetuto e doIt(Integer i)applicato alcuni a tutti i suoi membri, ogni volta con un metodo diverso. nella classe Main eseguo il metodo testato tre volte per riscaldare la JVM. Eseguo quindi il metodo di prova 1000 volte sommando il tempo necessario per ciascun metodo di iterazione (usando System.nanoTime()). Dopo aver fatto ciò divido quella somma per 1000 e questo è il risultato, tempo medio. esempio:

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

Ho eseguito questo su una CPU i5 4 core, con la versione java 1.8.0_05

classico for

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

tempo di esecuzione: 4,21 ms

foreach classico

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

tempo di esecuzione: 5,95 ms

List.forEach()

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

tempo di esecuzione: 3,11 ms

List.stream().forEach()

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

tempo di esecuzione: 2,79 ms

List.parallelStream().forEach

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

tempo di esecuzione: 3,6 ms

Sento che devo estendere un po 'il mio commento ...

A proposito di paradigma \ stile

Questo è probabilmente l'aspetto più notevole. FP è diventato popolare grazie a ciò che puoi ottenere evitando gli effetti collaterali. Non approfondirò quali vantaggi puoi trarre da questo, dal momento che questo non è correlato alla domanda.

Tuttavia, dirò che l'iterazione che utilizza Iterable.forEach è ispirata a FP e piuttosto il risultato del portare più FP a Java (ironicamente, direi che non c'è molto uso per ogni in FP puro, poiché non fa altro che introdurre effetti collaterali).

Alla fine direi che è piuttosto una questione di gusti \ stile \ paradigma in cui stai scrivendo.

Sul parallelismo.

Dal punto di vista delle prestazioni non ci sono notevoli vantaggi promessi dall'uso di Iterable.forOach over foreach (...).

Secondo i documenti ufficiali su Iterable.forEach :

Esegue l'azione data sul contenuto di Iterable, nell'ordine in cui gli elementi si verificano durante l'iterazione, fino a quando tutti gli elementi non sono stati elaborati o l'azione genera un'eccezione.

... vale a dire documenti abbastanza chiari che non ci sarà parallelismo implicito. Aggiungerne uno sarebbe una violazione di LSP.

Ora, ci sono "raccolte parallele" che sono promesse in Java 8, ma per lavorare con quelle che hai bisogno di me sono più esplicite e metti qualche cura in più per usarle (vedi la risposta di mschenk74 per esempio).

A proposito: in questo caso verrà utilizzato Stream.forEach e non garantisce che il lavoro effettivo verrà eseguito in parallelo (dipende dalla raccolta sottostante).

AGGIORNAMENTO: potrebbe non essere così ovvio e un po 'allungato a colpo d'occhio ma c'è un'altra sfaccettatura di stile e prospettiva di leggibilità.

Prima di tutto - i vecchi vecchi pianura sono semplici e vecchi. Tutti li conoscono già.

In secondo luogo, e più importante, probabilmente vorrai usare Iterable.forOach solo con lambda da una fodera. Se il "corpo" diventa più pesante, tendono a non essere così leggibili. Hai 2 opzioni da qui: usa le classi interne (schifo) o usa semplicemente il vecchio forloop. Le persone spesso si arrabbiano quando vedono che le stesse cose (iteratine sulle raccolte) vengono eseguite su vari vays / stili nella stessa base di codice, e questo sembra essere il caso.

Ancora una volta, questo potrebbe o non potrebbe essere un problema. Dipende dalle persone che lavorano al codice.

Una delle forEachlimitazioni della maggior parte delle funzioni di upleasing è la mancanza di supporto per le eccezioni verificate.

Una possibile soluzione è quella di sostituire il terminale forEachcon un semplice vecchio ciclo 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);
    }

Ecco un elenco delle domande più comuni con altre soluzioni alternative sulla gestione delle eccezioni verificate all'interno di lambdas e stream:

Funzione Java 8 Lambda che genera un'eccezione?

Java 8: Lambda-Streams, filtro per metodo con eccezione

Come posso generare eccezioni CHECKED dagli stream Java 8?

Java 8: gestione delle eccezioni verificata obbligatoria nelle espressioni lambda. Perché obbligatorio, non opzionale?

Il vantaggio del metodo Java 1.8 forEach su 1.7 Enhanced for loop è che durante la scrittura del codice è possibile concentrarsi solo sulla logica aziendale.

Il metodo forEach prende l'oggetto java.util.function.Consumer come argomento, quindi aiuta ad avere la nostra logica aziendale in una posizione separata per poterla riutilizzare in qualsiasi momento.

Dai un'occhiata allo snippet di seguito,

• Qui ho creato una nuova classe che sovrascriverà il metodo di classe da Consumer Class, dove è possibile aggiungere ulteriore funzionalità, Più che iterazione .. !!!!!!

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