Comportement parallèle du flux Java pour allMatch, noneMatch, filter et map

Question

J'ai lu dans un autre article qu'après une recherche on a trouvé que le fonctionnement du terminal anyMatch fonctionne de telle sorte que chaque thread (opérant sur un sous-flux) vérifie périodiquement si d'autres threads ont trouvé un résultat et si c'est le cas, tous les autres threads sont arrêtés.

je suppose, mais se demande si quelqu'un pouvait vérifier si noneMatch et allMatch fonctionnent également de cette façon, si lors de l'exécution noneMatch, un thread trouve une correspondance réelle, l'opération peut retourner false. Donc tous les autres threads vérifient-ils périodiquement cela de la même manière que pour anyMatch? De même, est-ce que l'inverse s'applique à allMatch?

En outre, je me suis demandé s'il y avait une différence lors de l'exécution des opérations filter et map en parallèle pour savoir si elles sont exécutées sur un flux ordonné ou non. Sur un flux ordonné, je suppose que l'avantage le plus logique est simplement que les différents threads peuvent traiter chaque sous-flux créé, puis les fusionner tous ensemble dans le même ordre. Pour un flux non ordonné, cela présente-t-il des avantages pour de telles opérations que j'ai du mal à imaginer?

Answer 1

Les trois anyMatch, allMatch et noneMatch sont implémentés en utilisant la même classe MatchOps avec différents drapeaux. Donc, ils travaillent de manière assez similaire. Tous sont en court-circuit et ne sont pas commandés, donc peu importe que la source de votre flux soit ordonnée ou non: ces opérations seront aussi rapides.

Les opérations comme map et filter n'ont aucun avantage avec une source non triée. Une source non ordonnée modifie l'algorithme pour distinct, limit, skip, takeWhile (Java-9), dropWhile (Java-9). Il semble que la réduction normale (via reduce ou collect) n'optimise pas le cas non ordonné (bien que mes recherches très préliminaires suggèrent qu'une telle optimisation serait possible).