Leçons

Patron comportemental « Observateur » : rôles Subject et Observer, abonnement/désabonnement via addObserver/ removeObserver, et diffusion des notifications par la méthode notifyObservers. Nous examinons le lien avec le modèle événementiel de Java : button. addActionListener( listener) ; → appel de actionPerformed(). Pratique sur des exemples (thermomètre et climatiseur, mini‑compteur et lambdas), ainsi que pourquoi java.util.Observable/ Observer sont obsolètes et quelles approches modernes existent.

Dans ce cours, nous expliquons ce qu’est le thread de distribution des événements de l’UI — EDT dans Swing et son équivalent JavaFX Application Thread, pourquoi les composants d’interface ne sont pas thread-safe et pourquoi la fenêtre « se fige » lors de tâches lourdes. Nous montrerons les bonnes pratiques : déporter les calculs en arrière-plan via new Thread(...), mettre à jour l’interface avec SwingUtilities.invokeLater et Platform.runLater, ainsi que l’utilisation d’outils de plus haut niveau SwingWorker<T, V> et Task<V>/ Service<V> pour la progression, l’annulation et la gestion des erreurs.

Pourquoi les programmes ont-ils besoin de threads et de parallélisme : de l’interface réactive à l’utilisation de tous les cœurs du processeur. Nous expliquons la différence entre processus et threads, le rôle du thread principal main dans la JVM, des cas pratiques (UI, serveurs, traitement de fichiers) et les risques : race condition, deadlock, ainsi que les outils de base de synchronisation comme synchronized. Nous montrerons un exemple simple avec Thread et le lancement de deux tâches en parallèle.

Dans cette leçon, nous abordons le lancement des threads en Java : nous faisons connaissance avec la classe Thread et l’interface Runnable, nous apprenons à appeler correctement start() sans le confondre avec run(), nous utilisons des classes anonymes et des expressions lambda, nous lançons plusieurs threads et observons le cycle de vie ( NEW → RUNNABLE → TERMINATED). Nous parlerons des méthodes Thread.currentThread(), getName(), de l’attente via join() et des erreurs typiques comme IllegalThreadStateException.

Nous passons en revue le cycle de vie d’un thread en Java : de Thread.State (

NEW

,

RUNNABLE

,

BLOCKED

,

WAITING

,

TIMED_WAITING

,

TERMINATED

) aux transitions entre eux. Nous apprenons à gérer les threads avec Thread.sleep(...), join(), interrupt(), à diagnostiquer l’état via isAlive() et getState(), ainsi qu’à éviter les méthodes obsolètes de type stop()/ suspend()/ resume(). À la fin — conseils pratiques et erreurs fréquentes.

Comment transmettre des paramètres en toute sécurité aux threads via le constructeur d’une classe qui implémente Runnable, quand les expressions lambda sont pertinentes, et pourquoi il vaut mieux déclarer les champs final. Nous abordons les priorités des threads : méthodes setPriority/ getPriority, constantes Thread.MIN_PRIORITY, Thread.NORM_PRIORITY, Thread.MAX_PRIORITY et leur influence sur l’ordonnanceur. En plus — nommage des threads via le constructeur, setName/ getName, exemple pratique et erreurs typiques (Runnable partagé, setters, espoirs dans les priorités).

Dans ce cours, nous expliquons ce qu’est une condition de concurrence : lorsque plusieurs threads accèdent simultanément à des données partagées et que le résultat dépend de l’ordre d’ordonnancement. À l’exemple de l’incrément counter ++, nous montrons pourquoi l’opération n’est pas atomique et comment des incréments se perdent. Nous examinons un cas pratique avec un compte bancaire, les conséquences en production et les approches de protection : synchronized, les types atomiques de java.util.concurrent.atomic (par exemple, AtomicInteger), ainsi que l’immuabilité. Nous terminons par une section « Erreurs typiques », où l’on explique pourquoi les bugs de Thread sont rarement détectés par les tests et pourquoi tenter de les « soigner » avec Thread. sleep( 1) est inutile.

Cette leçon explique ce qu’est une ressource partagée dans les applications multithread, pourquoi apparaissent les race conditions et les « mises à jour perdues », et comment protéger les données avec synchronized. Nous examinerons les techniques de base de synchronisation (méthodes et blocs), parlerons des outils modernes de java.util.concurrent ( Lock, ReentrantLock, Semaphore, etc.), et nous verrons des exemples pratiques avec l’incrément d’un compteur et les erreurs typiques (non-atomicité de i ++, mauvais objet de verrouillage, mythes autour de volatile).

Cours pratique sur le multithreading : nous expliquons le fonctionnement du mot-clé synchronized (blocs et méthodes, moniteur d’objet et verrouillage au niveau de la classe ClassName.class), en quoi la visibilité des changements via volatile diffère de l’atomicité des opérations, pourquoi il est pratique d’utiliser volatile pour les drapeaux boolean, et pourquoi l’incrément count ++ nécessite une synchronisation. Nous comparerons quand choisir synchronized et quand — volatile, et nous analyserons les erreurs typiques.

Comparaison pratique de la synchronisation classique via synchronized avec des primitives plus flexibles du paquet java.util.concurrent.locks : ReentrantLock et ReadWriteLock. Nous verrons comment gérer explicitement les verrous ( lock()/ unlock(), tryLock() avec délai d’attente), comment faire évoluer la lecture avec ReentrantReadWriteLock, ce qu’est l’« équité » ( fair mode), où chaque outil est pertinent et quelles erreurs surviennent le plus souvent.

Dans ce cours, nous passerons en revue les principaux primitifs de synchronisation en Java : comment protéger les sections critiques avec synchronized et la classe ReentrantLock (méthodes lock()/ unlock(), construction try- finally), ainsi que comment limiter le parallélisme avec Semaphore (méthodes acquire()/ release()). Nous comparerons le mutex et le sémaphore dans un tableau, examinerons des cas pratiques (banque, serveur avec limite de connexions) et les erreurs courantes menant à des deadlocks et à des pertes de performances.

Analyse pratique des erreurs fréquentes de concurrence en Java : unlock()/ release() oubliés avec ReentrantLock et Semaphore (à corriger via try- finally), choix d’un mauvais moniteur pour synchronized, interblocages (deadlock) et ordre de prise des verrous, synchronisation excessive, ainsi que limites d’application de volatile et remplacement par AtomicInteger. Exemples, conseils et analogies parlantes — pour que le code ne « se fige » pas.