Java 8 Iterable.forEach () vs foreach loop

¿Cuál de las siguientes es una mejor práctica en Java 8?

Java 8:

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

Java 7:

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

Tengo muchos bucles for que podrían "simplificarse" con lambdas, pero ¿hay alguna ventaja de usarlos? ¿Mejoraría su rendimiento y legibilidad?

EDITAR

También extenderé esta pregunta a métodos más largos. Sé que no puede devolver o romper la función principal de un lambda y esto también debe tenerse en cuenta al compararlos, pero ¿hay algo más que considerar?

La mejor práctica es usar for-each. Además de violar el principio estúpido Keep It Simple, el nuevo forEach()tiene al menos las siguientes deficiencias:

• No se pueden usar variables no finales . Por lo tanto, un código como el siguiente no se puede convertir en un lambda forEach:

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

• No se pueden manejar las excepciones marcadas . Las lambdas en realidad no tienen prohibido lanzar excepciones marcadas, pero las interfaces funcionales comunes como Consumerno declaran ninguna. Por lo tanto, cualquier código que arroje excepciones marcadas debe incluirlas en try-catcho Throwables.propagate(). Pero incluso si hace eso, no siempre está claro qué sucede con la excepción lanzada. Podría tragarse en algún lugar de las entrañas deforEach()

• Control de flujo limitado . A returnen una lambda es igual a a continueen for-each, pero no hay equivalente a a break. También es difícil hacer cosas como valores de retorno, cortocircuito o establecer indicadores (lo que habría aliviado un poco las cosas, si no fuera una violación de la regla de variables no finales ). "Esto no es solo una optimización, sino que es crítico cuando consideras que algunas secuencias (como leer las líneas en un archivo) pueden tener efectos secundarios, o puedes tener una secuencia infinita".

• Podría ejecutarse en paralelo , lo cual es una cosa horrible, horrible para todos menos el 0.1% de su código que necesita ser optimizado. Cualquier código paralelo debe ser pensado (incluso si no usa bloqueos, volátiles y otros aspectos particularmente desagradables de la ejecución tradicional de subprocesos múltiples). Cualquier error será difícil de encontrar.

• Podría dañar el rendimiento , porque el JIT no puede optimizar forEach () + lambda en la misma medida que los bucles simples, especialmente ahora que las lambdas son nuevas. Por "optimización" no me refiero a la sobrecarga de llamar a lambdas (que es pequeño), sino al análisis sofisticado y la transformación que el compilador JIT moderno realiza al ejecutar código.

• Si necesita paralelismo, probablemente sea mucho más rápido y no mucho más difícil usar un ExecutorService . Los flujos son automáticos (léase: no sé mucho acerca de su problema) y utilizan una estrategia de paralelización especializada (léase: ineficiente para el caso general) ( descomposición recursiva fork-join ).

• Hace que la depuración sea más confusa , debido a la jerarquía de llamadas anidadas y, Dios no lo quiera, la ejecución paralela. El depurador puede tener problemas para mostrar variables del código circundante y cosas como el paso a paso pueden no funcionar como se esperaba.

• Las transmisiones en general son más difíciles de codificar, leer y depurar . En realidad, esto es cierto para las API complejas " fluidas " en general. La combinación de declaraciones simples complejas, el uso intensivo de genéricos y la falta de variables intermedias conspiran para producir mensajes de error confusos y frustrar la depuración. En lugar de "este método no tiene una sobrecarga para el tipo X", aparece un mensaje de error más cercano a "en algún lugar donde confundió los tipos, pero no sabemos dónde ni cómo". Del mismo modo, no puede avanzar y examinar las cosas en un depurador tan fácilmente como cuando el código se divide en varias declaraciones, y los valores intermedios se guardan en variables. Finalmente, leer el código y comprender los tipos y el comportamiento en cada etapa de ejecución puede no ser trivial.

• Sobresale como un pulgar dolorido . El lenguaje Java ya tiene la instrucción for-each. ¿Por qué reemplazarlo con una llamada a función? ¿Por qué animar a ocultar los efectos secundarios en algún lugar de las expresiones? ¿Por qué alentar frases poco manejables? Mezclar regularmente para cada uno y nuevo para cada uno es un mal estilo. El código debe hablar en expresiones idiomáticas (patrones que son rápidos de comprender debido a su repetición), y cuanto menos expresiones idiomáticas se usen, más claro será el código y menos tiempo se decidirá qué idioma usar (¡una gran pérdida de tiempo para perfeccionistas como yo! )

Como puede ver, no soy un gran admirador de forEach () excepto en los casos en que tiene sentido.

Particularmente ofensivo para mí es el hecho de que Streamno se implementa Iterable(a pesar de tener un método iterator) y no se puede usar en for-each, solo con forEach (). Recomiendo transmitir Streams a Iterables con (Iterable<T>)stream::iterator. Una mejor alternativa es usar StreamEx, que corrige varios problemas de Stream API, incluida la implementación Iterable.

Dicho esto, forEach()es útil para lo siguiente:

• Atómicamente iterando sobre una lista sincronizada . Antes de esto, una lista generada con Collections.synchronizedList()era atómica con respecto a cosas como get o set, pero no era segura para subprocesos al iterar.

• Ejecución paralela (usando una secuencia paralela apropiada) . Esto le ahorra algunas líneas de código en comparación con el uso de un ExecutorService, si su problema coincide con los supuestos de rendimiento integrados en Streams y Spliterators.

• Contenedores específicos que , como la lista sincronizada, se benefician de tener el control de la iteración (aunque esto es en gran medida teórico a menos que las personas puedan presentar más ejemplos)

• Llamar a una sola función de manera más limpia mediante el uso de forEach()un argumento de referencia de método (es decir, list.forEach (obj::someMethod)). Sin embargo, tenga en cuenta los puntos sobre las excepciones marcadas, la depuración más difícil y la reducción de la cantidad de expresiones idiomáticas que utiliza al escribir código.

Artículos que utilicé para referencia:

• Todo sobre Java 8
• Iteración por dentro y por fuera (como señala otro póster)

EDITAR: Parece que algunas de las propuestas originales para lambdas (como http://www.javac.info/closures-v06a.html ) resolvieron algunos de los problemas que mencioné (al agregar sus propias complicaciones, por supuesto).

La ventaja se tiene en cuenta cuando las operaciones se pueden ejecutar en paralelo. (Ver http://java.dzone.com/articles/devoxx-2012-java-8-lambda-and - la sección sobre iteración interna y externa)

• La principal ventaja desde mi punto de vista es que la implementación de lo que se debe hacer dentro del ciclo puede definirse sin tener que decidir si se ejecutará en paralelo o secuencialmente.

• Si desea que su ciclo se ejecute en paralelo, simplemente puede escribir

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

  Tendrá que escribir un código extra para el manejo de hilos, etc.

Nota: Para mi respuesta, supuse que se une a la implementación de la java.util.Streaminterfaz. Si las uniones implementan solo la java.util.Iterableinterfaz, esto ya no es cierto.

Al leer esta pregunta, uno puede tener la impresión de que, Iterable#forEachen combinación con expresiones lambda, hay un atajo / reemplazo para escribir un ciclo tradicional para cada bucle. Esto simplemente no es cierto. Este código del OP:

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

se no pretende ser un atajo para la escritura

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

y ciertamente no debe usarse de esta manera. En su lugar se pretende como un acceso directo (aunque es no exactamente de la misma) para la escritura

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

Y es como un reemplazo para el siguiente código 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);
}

Reemplazar el cuerpo de un bucle con una interfaz funcional, como en los ejemplos anteriores, hace que su código sea más explícito: está diciendo que (1) el cuerpo del bucle no afecta el código circundante y el flujo de control, y (2) el El cuerpo del bucle puede reemplazarse con una implementación diferente de la función, sin afectar el código circundante. No poder acceder a variables no finales del alcance externo no es un déficit de funciones / lambdas, es un característica que distingue la semántica de Iterable#forEachla semántica de un ciclo tradicional para cada bucle. Una vez que uno se acostumbra a la sintaxis de Iterable#forEach, hace que el código sea más legible, porque inmediatamente obtiene esta información adicional sobre el código.

Los bucles tradicionales para cada uno seguirán siendo una buena práctica (para evitar el término usado en exceso " mejor práctica ") en Java. Pero esto no significa que Iterable#forEachdeba considerarse una mala práctica o un mal estilo. Siempre es una buena práctica utilizar la herramienta adecuada para hacer el trabajo, y esto incluye mezclar bucles tradicionales para cada uno Iterable#forEach, donde tenga sentido.

Desde las desventajas de Iterable#forEach ya se han discutido en este hilo, aquí hay algunas razones por las que probablemente desee usar Iterable#forEach:

• Para que su código sea más explícito: como se describió anteriormente,Iterable#forEach puede hacer que su código sea más explícito y legible en algunas situaciones.

• Para hacer que su código sea más extensible y mantenible: el uso de una función como cuerpo de un bucle le permite reemplazar esta función con diferentes implementaciones (consulte Patrón de estrategia ). Podría, por ejemplo, reemplazar fácilmente la expresión lambda con una llamada al método, que puede ser sobrescrita por subclases:

  joins.forEach(getJoinStrategy());

  Luego, podría proporcionar estrategias predeterminadas utilizando una enumeración, que implementa la interfaz funcional. Esto no solo hace que su código sea más extensible, sino que también aumenta la capacidad de mantenimiento porque desacopla la implementación del bucle de la declaración del bucle.

• Para hacer que su código sea más depurable: Separar la implementación del bucle de la declaración también puede facilitar la depuración, ya que podría tener una implementación de depuración especializada, que imprime mensajes de depuración, sin la necesidad de saturar su código principal if(DEBUG)System.out.println(). La implementación de depuración podría ser, por ejemplo, un delegado , que decora la implementación de la función real.

• Para optimizar el código de rendimiento crítico: al contrario de algunas de las afirmaciones en este hilo,Iterable#forEach no ya proporcionar un mejor rendimiento que un tradicional para-cada bucle, al menos cuando se utiliza ArrayList y funcionando en el modo hotspot "-client". Si bien este aumento de rendimiento es pequeño y despreciable para la mayoría de los casos de uso, hay situaciones en las que este rendimiento adicional puede marcar la diferencia. Por ejemplo, los mantenedores de bibliotecas seguramente querrán evaluar si algunas de sus implementaciones de bucle existentes deben reemplazarse Iterable#forEach.

  Para respaldar esta afirmación con hechos, he hecho algunos micro-puntos de referencia con Caliper . Aquí está el código de prueba (se necesita el último Caliper de 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++;
              }
          }
      }
  }

  Y aquí están los resultados:

  • Resultados para -client
  • Resultados para -server

  Cuando se ejecuta con "-client", Iterable#forEachsupera el bucle for tradicional sobre una ArrayList, pero sigue siendo más lento que iterar directamente sobre una matriz. Cuando se ejecuta con "-server", el rendimiento de todos los enfoques es casi el mismo.

• Para proporcionar soporte opcional para la ejecución en paralelo: Ya se ha dicho aquí, que la posibilidad de ejecutar la interfaz funcional Iterable#forEachen paralelo usando flujos es sin duda un aspecto importante. Como Collection#parallelStream()no garantiza que el ciclo se ejecute realmente en paralelo, uno debe considerar esto como una característica opcional . Al iterar sobre su lista con list.parallelStream().forEach(...);, usted dice explícitamente: Este ciclo admite la ejecución paralela, pero no depende de ello. De nuevo, esta es una característica y no un déficit.

  Al alejar la decisión de ejecución paralela de su implementación de bucle real, permite la optimización opcional de su código, sin afectar el código en sí, lo cual es algo bueno. Además, si la implementación predeterminada de flujo paralelo no se ajusta a sus necesidades, nadie le impedirá proporcionar su propia implementación. Por ejemplo, puede proporcionar una colección optimizada según el sistema operativo subyacente, el tamaño de la colección, la cantidad de núcleos y algunas configuraciones de preferencias:

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

  Lo bueno aquí es que su implementación de bucle no necesita conocer ni preocuparse por estos detalles.

forEach()se puede implementar para que sea más rápido que para cada ciclo, porque el iterable conoce la mejor manera de iterar sus elementos, a diferencia del iterador estándar. Entonces, la diferencia es un bucle interno o un bucle externo.

Por ejemplo, ArrayList.forEach(action)puede implementarse simplemente como

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

a diferencia del ciclo for-each que requiere muchos andamios

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

Sin embargo, también tenemos que contabilizar dos costos generales utilizando forEach() , uno está haciendo el objeto lambda, el otro está invocando el método lambda. Probablemente no sean significativos.

ver también http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/ para comparar iteraciones internas / externas para diferentes casos de uso.

TL; DR : List.stream().forEach()fue el más rápido.

Sentí que debería agregar mis resultados de la iteración de benchmarking. Tomé un enfoque muy simple (sin marcos de referencia) y comparé 5 métodos diferentes:

1. clásico for
2. foreach clásico
3. List.forEach()
4. List.stream().forEach()
5. List.parallelStream().forEach

el procedimiento de prueba y los parámetros

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 lista de esta clase se repetirá y se doIt(Integer i)aplicará a todos sus miembros, cada vez a través de un método diferente. en la clase Main ejecuté el método probado tres veces para calentar la JVM. Luego ejecuto el método de prueba 1000 veces sumando el tiempo que toma cada método de iteración (usando System.nanoTime()). Una vez hecho esto, divido esa suma entre 1000 y ese es el resultado, el tiempo promedio. ejemplo:

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

Ejecuté esto en una CPU i5 de 4 núcleos, con la versión java 1.8.0_05

clásico for

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

tiempo de ejecución: 4.21 ms

foreach clásico

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

tiempo de ejecución: 5.95 ms

List.forEach()

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

tiempo de ejecución: 3.11 ms

List.stream().forEach()

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

tiempo de ejecución: 2.79 ms

List.parallelStream().forEach

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

tiempo de ejecución: 3.6 ms

Siento que necesito extender mi comentario un poco ...

Sobre paradigma \ estilo

Ese es probablemente el aspecto más notable. FP se hizo popular debido a lo que puede obtener evitando los efectos secundarios. No profundizaré en las ventajas y desventajas que puede obtener de esto, ya que esto no está relacionado con la pregunta.

Sin embargo, diré que la iteración usando Iterable.forEach está inspirada en FP y más bien es el resultado de traer más FP a Java (irónicamente, diría que no hay mucho uso para forEach en FP puro, ya que no hace nada más que introducir efectos secundarios).

Al final, diría que es más bien una cuestión de gusto \ estilo \ paradigma en el que está escribiendo actualmente.

Sobre el paralelismo.

Desde el punto de vista del rendimiento, no se prometen beneficios notables al usar Iterable.forEach sobre foreach (...).

Según los documentos oficiales de Iterable.forEach :

Realiza la acción dada sobre el contenido del Iterable, en el orden en que ocurren los elementos al iterar, hasta que todos los elementos hayan sido procesados ​​o la acción arroje una excepción.

... es decir, los documentos dejan bastante claro que no habrá paralelismo implícito. Agregar uno sería una violación de LSP.

Ahora, hay "colecciones paralelas" que se prometen en Java 8, pero para trabajar con ellas es necesario que sea más explícito y tenga especial cuidado para usarlas (consulte la respuesta de mschenk74 por ejemplo).

Por cierto: en este caso se utilizará Stream.forEach , y no garantiza que el trabajo real se realizará en paralelo (depende de la colección subyacente).

ACTUALIZACIÓN: puede no ser tan obvio y un poco estirado de un vistazo, pero hay otra faceta de estilo y perspectiva de legibilidad.

En primer lugar, los viejos bucles simples son simples y antiguos. Todos ya los conocen.

En segundo lugar, y más importante: probablemente quiera usar Iterable.forEach solo con lambdas de una línea. Si el "cuerpo" se vuelve más pesado, tienden a no ser tan legibles. Tiene 2 opciones desde aquí: use clases internas (yuck) o use forloop antiguo. La gente a menudo se molesta cuando ve que las mismas cosas (iteraciones sobre colecciones) se realizan en varios estilos / estilos en la misma base de código, y este parece ser el caso.

Nuevamente, esto podría o no ser un problema. Depende de las personas que trabajan en el código.

Una de las limitaciones de las funciones más novedosas forEaches la falta de compatibilidad con excepciones comprobadas.

Una posible solución alternativa es reemplazar la terminal forEachcon un antiguo bucle foreach simple:

    Stream<String> stream = Stream.of("", "1", "2", "3").filter(s -> !s.isEmpty());
    Iterable<String> iterable = stream::iterator;
    for (String s : iterable) {
        fileWriter.append(s);
    }

Aquí hay una lista de las preguntas más populares con otras soluciones sobre el manejo de excepciones comprobadas en lambdas y streams:

¿La función Java 8 Lambda que arroja una excepción?

Java 8: Lambda-Streams, filtro por método con excepción

¿Cómo puedo lanzar excepciones COMPROBADAS desde las secuencias Java 8?

Java 8: manejo obligatorio de excepciones controladas en expresiones lambda. ¿Por qué obligatorio, no opcional?

La ventaja de Java 1.8 para cada método sobre 1.7 Enhanced for loop es que al escribir código puede centrarse solo en la lógica de negocios.

Cada método toma el objeto java.util.function.Consumer como argumento, por lo que ayuda a tener nuestra lógica de negocios en una ubicación separada que puede reutilizar en cualquier momento.

Mira el fragmento de abajo,

• Aquí he creado una nueva Clase que anulará el método de aceptación de la Clase del Consumidor, donde puede agregar funcionalidad adicional, ¡Más que iteración ...!

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