Concurrence en Java : threads, executors et virtual threads

La concurrence est un grand classique des certifications Java — et une source d’erreurs en production. Comprendre les concepts et les bonnes API évite les deux écueils : les bugs subtils et les questions pièges.

Le thread, brique de base

Un thread exécute du code en parallèle. L’API bas niveau existe, mais on l’utilise rarement directement :

Thread t = new Thread(() -> System.out.println("Bonjour depuis " + Thread.currentThread()));
t.start();
t.join(); // attend la fin

Les executors : ne gérez pas les threads à la main

En pratique, on délègue à un pool via ExecutorService. On raisonne en tâches, pas en threads :

ExecutorService pool = Executors.newFixedThreadPool(4);
Future<Integer> f = pool.submit(() -> 21 * 2);
System.out.println(f.get()); // 42
pool.shutdown();

Le piège de l’état partagé

Deux threads qui modifient la même variable sans synchronisation produisent un résultat imprévisible (race condition). Les parades :

• synchronized ou ReentrantLock pour protéger une section critique.
• Les classes java.util.concurrent.atomic (ex. AtomicInteger).
• L’immuabilité : pas d’état partagé mutable, pas de problème.

Java 21 : les virtual threads

Les virtual threads (projet Loom) rendent les threads quasi gratuits : on peut en lancer des millions. Idéal pour les charges I/O.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 10_000; i++) {
        executor.submit(() -> { Thread.sleep(1000); return null; });
    }
} // chaque tâche sur son propre virtual thread

À retenir pour l’examen : un thread plateforme est coûteux, un virtual thread non ; et la sécurité de la concurrence reste ta responsabilité, virtual ou pas.