¿Cómo funcionan los streams por dentro, y cuándo usarías un stream paralelo?

Un stream construye una tubería de operaciones intermedias perezosas que no hace nada hasta que se ejecuta una operación terminal, y entonces los elementos fluyen en una sola pasada, y por eso importa filtrar antes de mapear. Los streams paralelos reparten la fuente sobre el ForkJoinPool común compartido. Úsalos solo para trabajo grande, fácil de partir, intensivo en CPU y sin estado mutable compartido, y nunca para E/S bloqueante, porque atarías un pool que comparte toda la aplicación.

Las operaciones intermedias solo construyen una tubería; no pasa nada hasta que una operación terminal tira de los elementos, y cada elemento se empuja por toda la cadena en vez de recorrer la colección una vez por operación. Por eso importa el orden, filtrar pronto hace menos trabajo, y por eso operaciones de cortocircuito como findFirst pueden parar la fuente entera antes de tiempo. Con los streams paralelos soy cauto. Reparten la fuente y corren sobre el ForkJoinPool común, que comparte toda la JVM, así que un stream paralelo lento en una petición puede retrasar todo lo demás que lo use. Eso descarta cualquier trabajo bloqueante: he visto un stream paralelo haciendo llamadas HTTP dejar sin recursos a todos los demás streams paralelos del proceso. Donde de verdad ayudan es en un cálculo grande en memoria sobre un array o un ArrayList, que se parten bien, sin estado mutable compartido y sin dependencia de orden. Aun así hago benchmarks, porque el coste de partir y unir se suele comer la ganancia en colecciones de unos pocos miles de elementos. Si necesito un pool dedicado, ejecuto el stream dentro de mi propio ForkJoinPool en vez del común.