Stream API vs Flux : différences pour les développeurs Java | Guide

Stream API vs Flux : Différences architecturales et applications pratiques

Comprendre les différences entre Stream API et Flux est crucial pour les développeurs Java travaillant avec des systèmes asynchrones. Malgré des similarités dans les méthodes (filter, map, limit), ces outils résolvent des problèmes fondamentalement différents. Stream API est conçu pour le traitement synchrone de collections finies, tandis que Flux de Project Reactor est destiné au traitement réactif de données en streaming avec gestion du backpressure et support de l'asynchronie. Cet article détaille les différences architecturales clés et vous aide à choisir l'outil adapté à votre besoin.

Bases de Stream API : Traitement synchrone des collections

Stream API est le mécanisme intégré de Java pour le traitement déclaratif des collections. Sa caractéristique principale : travailler avec des ensembles de données finis dans un seul thread d'exécution. L'appel à .stream() crée un flux séquentiel qui traite les éléments dans le même thread où il a été initié (par exemple, le thread principal).

Il est important de se rappeler la distinction des opérations :

• Opérations intermédiaires (filter, map, flatMap, limit, skip) — construisent une chaîne de transformations sans exécution immédiate. Elles retournent un nouveau flux et peuvent être chaînées indéfiniment.
• Opérations terminales (collect, forEach, reduce) — déclenchent toute la chaîne et ferment le flux. Après leur appel, le flux ne peut plus être réutilisé.

Considérons un exemple de filtrage et de transformation de données :

List<Integer> numbers = List.of(1, 2, 3, 4, 5);
numbers.stream()
    .filter(n -> n % 2 == 0)
    .map(n -> n * 2)
    .forEach(System.out::println); // 4, 8

Ici :

• filter conserve les nombres pairs
• map double chaque élément
• forEach déclenche l'exécution et affiche le résultat

Une limitation critique de Stream API est son usage unique. Toute tentative d'ajouter une autre opération terminale provoque une IllegalStateException. C'est une différence fondamentale par rapport aux flux réactifs.

Flux : Traitement réactif des données en streaming

Flux de Project Reactor implémente la spécification Reactive Streams pour le traitement asynchrone de flux de données non bornés. Contrairement à Stream API, Flux supporte :

• Une exécution non bloquante
• Le backpressure (contrôle du débit de consommation des données)
• La gestion d'erreurs via des opérateurs réactifs
• L'abonnement à des événements dans n'importe quel thread

Différences architecturales clés :

• Opération terminale — .subscribe() est requis pour démarrer le traitement. Sans cela, Flux reste « froid » et ne génère pas de données.
• Initialisation paresseuse — les données ne sont générées qu'après l'abonnement.
• Support de flux non bornés — Flux gère les sources infinies (par exemple, des données de capteurs en temps réel).

Opération équivalente en Flux :

Flux.just(1, 2, 3, 4, 5)
    .filter(n -> n % 2 == 0)
    .map(n -> n * 2)
    .subscribe(System.out::println); // 4, 8

Ici, .subscribe() non seulement démarre le traitement mais gère aussi le cycle de vie du flux. Flux traite les erreurs avec .onErrorResume() et régule le flux avec .limitRate().

Différences critiques : Tableau comparatif

Pour plus de clarté, voici un récapitulatif structuré des différences clés :

• Modèle d'exécution

- Stream API : traitement synchrone et bloquant

- Flux : traitement asynchrone et non bloquant avec backpressure

• Type de données

- Stream API : collections finies uniquement

- Flux : flux finis et infinis

• Gestion d'erreurs

- Stream API : exceptions lancées directement (nécessite try/catch)

- Flux : gestion d'erreurs intégrée via opérateurs (onErrorResume, retry)

• Réutilisabilité

- Stream API : usage unique après opération terminale

- Flux : abonnements multiples à un même flux (avec configuration appropriée)

• Parallélisme

- Stream API : .parallelStream() distribue sur les cœurs CPU

- Flux : .publishOn() et .subscribeOn() contrôlent le contexte d'exécution

Cas d'usage pratique : Transformation de données dans des scénarios réels

Considérons la mise à jour d'une collection d'employés et de leurs grades dans un HashMap. Exigences :

• Pour les employés Junior, passer le grade à Middle
• Ajouter l'étiquette « (promoted) »
• Retourner la structure mise à jour

Implémentation avec Stream API :

Map<String, String> updatedEmployees = employees.entrySet().stream()
    .map(entry -> {
        String grade = entry.getValue();
        if ("Junior".equals(grade)) {
            return Map.entry(entry.getKey(), "Middle (increased)");
        }
        return entry;
    })
    .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

Même scénario avec Flux :

Map<String, String> updatedEmployees = Flux.fromStream(employees.entrySet().stream())
    .map(entry -> {
        if ("Junior".equals(entry.getValue())) {
            return Map.entry(entry.getKey(), "Middle (increased)");
        }
        return entry;
    })
    .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue))
    .block();

Différences d'implémentation clés :

• Flux nécessite un .block() explicite pour obtenir le résultat (ce qui va à l'encontre des principes réactifs)
• Stream API bloque le thread d'exécution jusqu'à completion
• Pour les systèmes réactifs, préférez le non-bloquant via .subscribe()

Points clés à retenir

• Stream API — idéal pour le traitement synchrone de collections finies dans un seul thread. À utiliser pour les opérations ETL ou les transformations de données en logique métier.
• Flux — gère les données en streaming asynchrones. Parfait pour les requêtes réseau, capteurs ou bus d'événements.
• Backpressure — fonctionnalité critique de Flux absente de Stream API. Maintient la stabilité des systèmes sous forte charge.
• Gestion d'erreurs — réactive dans Flux, try/catch traditionnel dans Stream API.
• Performances — Stream API l'emporte pour les opérations sync courtes ; Flux pour les processus async longs.

— Editorial Team