Pourquoi `filter()` semble-t-il non paresseux après `flatMap()` dans Java Streams ?

Pourquoi filter() n'est-il pas "complètement" paresseux après flatMap() dans les flux Java ?

Dans les flux Java 8, les opérations intermédiaires comme filter() et flatMap() sont paresseux, ce qui signifie qu'ils ne s'exécutent pas tant qu'une opération de terminal comme findFirst() n'est pas appelée. Cependant, lorsque filter() suit flatMap(), cette paresse n'est pas entièrement réalisée, ce qui conduit à un comportement inattendu.

Considérez cet exemple de code :

Stream.of(1, 2, 3)
        .filter(i -> {
            System.out.println(i);
            return true;
        })
        .findFirst()
        .get();

La sortie montre que seul le premier L'élément est imprimé, indiquant que filter() est paresseux et court-circuite lorsque la condition est remplie. En revanche :

Stream.of(1, 2, 3)
        .flatMap(i -> Stream.of(i - 1, i, i + 1))
        .flatMap(i -> Stream.of(i - 1, i, i + 1))
        .filter(i -> {
            System.out.println(i);
            return true;
        })
        .findFirst()
        .get();

Étonnamment, tous les éléments sont imprimés. Même si filter() remplit immédiatement sa condition, il continue de traiter les éléments suivants du flux.

La raison

Ce comportement est dû à l'implémentation de Java Streams. Après flatMap(), le flux ne contient plus les éléments d'origine. Au lieu de cela, il contient une séquence d'éléments aplatis générés par flatMap(). Lorsque filter() suit, il opère sur ces éléments aplatis, pas sur le flux d'origine.

L'implémentation de forEachWithCancel(), qui est utilisée dans findFirst(), appelle en permanence tryAdvance() sur le séparateur jusqu'à ce que le récepteur demande l'annulation ou le séparateur est épuisé. Dans le cas de flatMap(), le séparateur continue d'avancer sans aucune possibilité de résiliation anticipée, même lorsque filter() a déjà trouvé une correspondance.

Correction

Ce problème a été résolu dans Java 10 et rétroporté vers Java 8. L'implémentation permet désormais une terminaison anticipée dans flatMap() lorsqu'une opération de court-circuit telle que filter() est utilisé.

Conclusion

Naturellement, il peut être déroutant de savoir pourquoi filter() se comporte comme s'il n'était pas paresseux après flatMap(). L'implémentation sous-jacente de Java Streams dicte ce comportement, qui a ensuite été corrigé dans Java 10 et rétroporté vers Java 8. Cette compréhension est cruciale pour gérer efficacement de tels scénarios.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!