Wie funktionieren Streams unter der Haube, und wann würdest du einen Parallel Stream nehmen?

Ein Stream baut eine Pipeline aus faulen Zwischenoperationen, die nichts tut, bis eine Terminaloperation läuft, und dann fließen die Elemente in einem Durchgang durch, weshalb filter vor map einen Unterschied macht. Parallel Streams teilen die Quelle auf den gemeinsamen Common ForkJoinPool auf. Nimm sie nur für große, billig aufteilbare, CPU-lastige Arbeit ohne geteilten veränderlichen Zustand, und nie für blockierendes I/O, weil du damit einen Pool blockierst, den die ganze Anwendung teilt.

Zwischenoperationen bauen nur eine Pipeline; es passiert nichts, bis eine Terminaloperation Elemente hindurchzieht, und jedes Element wird durch die gesamte Kette geschoben, statt die Collection einmal pro Operation zu durchlaufen. Deshalb spielt die Reihenfolge eine Rolle, frühes Filtern spart Arbeit, und deshalb können kurzschließende Operationen wie findFirst die ganze Quelle vorzeitig stoppen. Bei Parallel Streams bin ich vorsichtig. Sie teilen die Quelle auf und laufen auf dem Common ForkJoinPool, den sich die gesamte JVM teilt, ein langsamer Parallel Stream in einem Request kann also alles andere verzögern, das ihn benutzt. Damit fällt jede blockierende Arbeit raus: ich habe erlebt, wie ein Parallel Stream mit HTTP-Calls jeden anderen Parallel Stream im Prozess ausgehungert hat. Wo sie wirklich helfen, ist eine große In-Memory-Berechnung über ein Array oder eine ArrayList, die sich gleichmäßig aufteilen lassen, ohne geteilten veränderlichen Zustand und ohne Abhängigkeit von der Reihenfolge. Selbst dann benchmarke ich, weil der Overhead fürs Aufteilen und Zusammenführen den Gewinn bei Collections mit ein paar tausend Elementen oft auffrisst. Brauche ich einen eigenen Pool, lasse ich den Stream in meinem eigenen ForkJoinPool laufen statt im Common Pool.