Java Academy · Leçon

Identifier les goulots d’étranglement

Mesurez avant d’optimiser

Identifier les goulots d’étranglement est une leçon Java Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Java Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Java Academy comprend 4 leçons au total.

Mesurez, ne devinez pas

La première règle pour améliorer les performances : mesurez avant d’optimiser.

L’intuition concernant l’endroit où un programme Java passe son temps est généralement trompeuse. Le compilateur à la volée, le ramasse-miettes et la mise en cache déjouent les suppositions. Profilez, trouvez le véritable point chaud, puis corrigez-le.

Définition d’un goulot d’étranglement

Un goulot d’étranglement est la partie du système qui limite le débit global ou la latence.

Optimiser autre chose n’apporte aucun avantage visible. La loi d’Amdahl le formalise : si 90 % du temps est consacré à une méthode, accélérer les 10 % restants ne peut jamais apporter plus de 11 % d’amélioration.

Latence ou débit

Décidez ce que vous cherchez à optimiser :

Latence — la durée d’une requête.
Débit — le nombre de requêtes par seconde.

Ces objectifs s’opposent. Le traitement par lots améliore le débit, mais peut augmenter la latence de chaque requête. Définissez votre objectif avant d’ajuster le système.

Mesure avec l’horloge réelle

La mesure la plus rudimentaire consiste à mesurer le temps réel autour d’un bloc de code avec System.nanoTime().

C’est utile pour une vérification rapide, mais cette mesure inclut l’échauffement du compilateur à la volée, les pauses du ramasse-miettes et les perturbations liées à la planification du système d’exploitation. Méfiez-vous donc des valeurs isolées.

public class Main {
    public static void main(String[] args) {
        long start = System.nanoTime();
        long sum = 0;
        for (int i = 0; i < 10_000_000; i++) sum += i;
        long elapsed = System.nanoTime() - start;
        System.out.println("Sum: " + sum);
        System.out.println("Elapsed ms: " + (elapsed / 1_000_000.0));
    }
}

Attention à l’échauffement de la compilation à la volée

Java commence par interpréter le code intermédiaire, puis le compilateur à la volée compile les méthodes très sollicitées en code machine.

Les premières exécutions d’une méthode sont donc bien plus lentes que les suivantes. Une boucle de mesure naïve mesure principalement l’échauffement. Les véritables évaluations de performance commencent par une phase d’échauffement, puis mesurent le régime stable : c’est exactement ce que JMH fait pour vous.

Limité par le CPU ou par les IO

Classez le goulot d’étranglement :

Limité par le CPU — les fils d’exécution calculent activement et les cœurs sont saturés.
Limité par les IO — les fils d’exécution attendent le disque, le réseau ou la base de données.

Les outils de profilage distinguent ces situations par le temps « sur le CPU » et le temps « bloqué ou en attente ». La correction est complètement différente : algorithmes plus rapides, davantage de concurrence ou moins d’allers-retours.

Échantillonnage et instrumentation

Deux stratégies de profilage :

Échantillonnage — capture périodiquement les traces de pile. Faible surcharge, résultat statistique.
Instrumentation — injecte des compteurs dans chaque méthode. Résultat exact, mais coût élevé, avec un risque de fausser les mesures.

En production, préférez un échantillonnage à faible surcharge, comme l’enregistreur de vol de Java.

La mémoire comme goulot d’étranglement

Souvent, le véritable coût vient de l’allocation, et non des calculs. La création excessive d’objets déclenche des ramassages mémoire fréquents, mobilise du CPU et ajoute des pauses.

Surveillez le débit d’allocation et le temps consacré au ramassage mémoire. Réduire les allocations dans une boucle très sollicitée est souvent plus efficace que d’affiner les calculs arithmétiques.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        // Allocation-heavy: a new String each iteration
        List<String> garbage = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            garbage.add("item-" + i);
        }
        System.out.println("Allocated " + garbage.size() + " strings");
        System.out.println("In a hot loop, this churn drives GC pressure");
    }
}

Trouver le sommet de la pile

Un profileur par échantillonnage produit une liste de méthodes classées selon la fréquence à laquelle elles apparaissent dans une pile d’exécution du CPU : c’est le temps propre.

La méthode en tête de liste est votre candidate. Vérifiez toutefois qu’elle se trouve sur le chemin critique : une méthode très sollicitée qui s’exécute dans un système de journalisation en arrière-plan peut ne pas affecter la latence ressentie par l’utilisateur.

Établir une mesure de référence

Avant de modifier quoi que ce soit, enregistrez une mesure de référence sous une charge réaliste.

Après chaque modification, mesurez à nouveau et comparez. Sans mesure de référence, vous ne pouvez pas prouver qu’une optimisation a été utile, et de nombreuses « optimisations » dégradent les performances. Ne modifiez qu’une seule chose à la fois.

Profilez sous une charge réaliste

Un goulet d’étranglement trouvé sur un ordinateur portable inactif n’est peut-être pas celui qui pénalise la production.

Utilisez des tailles de données et un niveau de concurrence représentatifs.
Reproduisez la charge de travail qui compte réellement pour les utilisateurs.

Les micro-essais synthétiques peuvent vous orienter vers une méthode sans importance à grande échelle. Profilez là où se trouve réellement le problème.

Vérification rapide

Pourquoi les mesures uniques et naïves de System.nanoTime() d’une méthode Java sont-elles souvent trompeuses ?

Récapitulatif

Rechercher les goulets d’étranglement avec méthode :

Mesurez avant d’optimiser : l’intuition vous trompe.
Choisissez un objectif : la latence ou le débit.
Déterminez si la charge est limitée par le CPU ou par les IO ; surveillez le ramasse-miettes et les allocations.
Privilégiez les outils de profilage par échantillonnage et à faible surcharge.
Méfiez-vous de la phase de chauffe de la compilation à la volée ; établissez une référence de base et ne modifiez qu’un seul élément à la fois.

Questions Fréquemment Posées

La leçon « Identifier les goulots d’étranglement » est-elle gratuite ?

Oui — le texte complet de « Identifier les goulots d’étranglement » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Java Academy, passe à CoddyKit PRO. Le cours Java Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Identifier les goulots d’étranglement » ?

Mesurez avant d’optimiser Tu pratiques Java Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Java Academy ?

Aucune expérience préalable n'est requise. Java Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Identifier les goulots d’étranglement » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Java Academy ?

Oui. Chaque leçon Java Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

← Retour à Java Academy