Lambdas, streams et réductions

Comprendre le mécanisme

Une lambda implémente une interface fonctionnelle et ne capture que des variables locales finales ou effectivement finales. Un stream décrit un pipeline : les opérations intermédiaires sont généralement paresseuses et une opération terminale déclenche le traitement nécessaire. Un stream consommé ne doit pas être réutilisé. map transforme chaque élément ; flatMap aplatit des flux imbriqués. Optional exprime une présence possible, sans autoriser un get aveugle.

Raisonner et vérifier

Une réduction parallèle exige notamment une combinaison associative et une identité adaptée. Modifier une liste extérieure dans forEach introduit un état partagé et peut rompre la sûreté du traitement. Préférez des collecteurs qui construisent le résultat. Ne faites pas reposer une obligation métier sur peek : certaines optimisations ou opérations terminales peuvent éviter le parcours imaginé.

Construire un pipeline sans le consommer

Des opérations intermédiaires comme filter et map décrivent un traitement qui peut être paresseux. L’exécution nécessaire se produit avec une opération terminale selon le contrat du stream. Une chaîne de méthodes ne prouve donc pas que tous les effets ont déjà eu lieu à la création. Pour comprendre un résultat, identifiez source, étapes intermédiaires et terminal, puis tracez les valeurs qui traversent réellement chaque étape.

Une consommation n’est pas une collection réutilisable

Un stream possède un cycle de vie et ne doit généralement pas être réutilisé après une opération terminale. Pour recommencer un parcours, créez un nouveau stream depuis la source ou fournissez un mécanisme qui le produit. Conserver une référence au stream ne le transforme pas en cache de résultats. Le test utile réalise deux parcours distincts depuis la source au lieu de répéter une consommation invalide.

Capture locale et état effectivement final

Une lambda peut capturer une variable locale finale ou effectivement finale. Réaffecter ensuite cette variable rompt ce contrat ; la compiler n’est pas rendu possible parce que la lambda s’exécute plus tard. Cette règle ne gèle pas tous les objets référencés par la variable. Un objet mutable peut encore porter des effets partagés : l’absence de réaffectation de référence ne prouve pas une fonction pure.

Réduire avec une loi adaptée

Une réduction parallèle peut regrouper les opérations dans des ordres différents. La combinaison doit donc être associative avec une identité adaptée au contrat choisi. Une soustraction arbitraire ne possède pas cette propriété : changer les regroupements peut changer le résultat. Écrivez la loi attendue sur un petit jeu de valeurs et comparez plusieurs regroupements avant de conclure que la parallélisation préserve votre calcul.

Éviter les effets partagés non protégés

Écrire dans une ArrayList partagée depuis un stream parallèle n’acquiert pas automatiquement une protection de concurrence. Même lorsque le résultat semble correct lors d’un essai, des entrelacements différents peuvent perdre ou corrompre des opérations. Préférez une collecte et une combinaison adaptées au stream lorsque c’est le besoin. Les effets externes, comme envoyer des messages, demandent aussi une politique d’ordre, de reprise et de doublons.

Le terminal définit le résultat

Un terminal peut produire une somme, une liste, une valeur optionnelle ou un effet selon l’opération choisie. Il faut donc lire son contrat au lieu de supposer que toute chaîne renvoie une collection. Une somme après filtre ne porte que sur les éléments conservés. Tracez la cardinalité et le type après chaque transformation ; cette méthode permet de vérifier un résultat sans exécuter mentalement toutes les méthodes en bloc.

Représenter l’absence avec Optional

Un résultat Optional annonce qu’une valeur peut être absente. Il ne justifie pas un accès supposant systématiquement sa présence. Définissez comment le consommateur traite le cas vide : valeur de repli, autre traitement ou erreur explicitement choisie. Évitez un défaut qui transforme une absence significative en valeur métier trompeuse. Les tests doivent établir le comportement pour une source vide et pour un élément effectivement trouvé.

Ordre de rencontre et ordre des effets

L’ordre d’une source et les garanties de l’opération terminale influencent ce qui peut être observé. Le parallélisme ne promet pas que tout effet externe apparaisse dans un ordre intuitif. Si le contrat public exige une séquence, choisissez les opérations qui la préservent ou séparez le calcul de la publication. Une impression console nominale ne suffit pas à démontrer une garantie d’ordre sous toutes les exécutions.

Mesurer avant de paralléliser

Le traitement parallèle introduit une distribution du travail et des coûts de coordination. Sur une petite collection ou une opération très courte, ces coûts peuvent dépasser le gain. La nature des dépendances et des ressources partagées compte aussi. Mesurez sur des données représentatives et conservez le même contrat de résultat. Le mot parallel ne crée ni cœurs supplémentaires ni réduction universelle de la latence.

Ne pas modifier la source pendant le parcours

Le contrat de non-interférence évite de transformer arbitrairement la source pendant que le pipeline la parcourt. Une mutation cachée dans un callback peut rendre le raisonnement dépendant d’un ordre ou d’une implémentation. Séparez préparation des données et traitement, ou utilisez un modèle explicitement conçu pour la concurrence nécessaire. Un test doit explorer les cas de source partagée au lieu de conclure depuis une seule exécution locale.

Atelier guidé : lire, expliquer et vérifier le code

import java.util.List;
class Main {
    public static void main(String[] args) {
        var source = List.of(1, 2, 3);
        int sum = source.stream().filter(n -> n > 1).mapToInt(n -> n * 2).sum();
        System.out.print(sum);
    }
}

Le filtre de l’exercice retire 1 et conserve 2 puis 3. mapToInt transforme ces valeurs en 4 et 6, et sum déclenche le parcours utile avant d’additionner les résultats. La sortie vaut donc 10. Ni la somme de la source seule ni le double de toute la source ne respecte l’ordre des transformations montrées.

Rejouez le programme en retirant temporairement le terminal pour observer que la simple construction du pipeline n’est pas la même opération. Ajoutez ensuite une source vide et vérifiez le résultat défini par le terminal. Si vous envisagez une version parallèle, examinez séparément l’associativité de la réduction et les effets éventuels des callbacks ; la simplicité de cet exemple ne constitue pas une preuve pour tous les traitements.