Como streams funcionam por baixo dos panos, e quando você usaria um parallel stream?

Um stream monta um pipeline de operações intermediárias preguiçosas que não fazem nada até uma operação terminal rodar, e aí os elementos passam numa única passada, e é por isso que filtrar antes de mapear importa. Parallel streams dividem a fonte no common ForkJoinPool compartilhado. Use só para trabalho grande, facilmente divisível, CPU bound e sem estado mutável compartilhado, e nunca para I/O bloqueante, porque você amarraria um pool que a aplicação inteira compartilha.

Operações intermediárias só montam um pipeline; nada acontece até uma operação terminal puxar os elementos, e cada elemento é empurrado pela cadeia inteira em vez de a coleção ser percorrida uma vez por operação. É por isso que a ordem importa, filtrar cedo faz menos trabalho, e por isso operações de curto circuito como findFirst conseguem parar a fonte inteira mais cedo. Com parallel streams eu sou cauteloso. Eles dividem a fonte e rodam no common ForkJoinPool, que é compartilhado pela JVM inteira, então um parallel stream lento numa requisição pode atrasar todo o resto que usa ele. Isso descarta qualquer trabalho bloqueante: eu já vi um parallel stream fazendo chamadas HTTP matar de fome todos os outros parallel streams do processo. Onde eles realmente ajudam é numa computação grande em memória sobre um array ou um ArrayList, que dividem de forma uniforme, sem estado mutável compartilhado e sem dependência de ordem. Mesmo assim eu meço, porque o custo de dividir e juntar costuma comer o ganho em coleções de poucos milhares de elementos. Se eu preciso de um pool dedicado, eu rodo o stream dentro do meu próprio ForkJoinPool em vez do common.