Réponse.

Historique de la question :

Lorsque Java est apparu pour la première fois, il n'existait pas de description formelle de la manière dont la mémoire et les threads interagissaient entre eux. En conséquence, les mêmes programmes pouvaient se comporter différemment sur différentes JVM, ce qui entraînait des bugs difficiles à attraper. En 2004, le modèle de mémoire Java (JMM) a été ajouté à la spécification Java, visant à définir strictement comment les threads voient les mises à jour des variables.

Problème :

Sans un modèle de mémoire clair, les opérations d'écriture et de lecture peuvent être mélangées par le compilateur ou le processeur, ce qui entraîne un comportement inattendu lors de l'accès à des variables partagées depuis différents threads. Cela peut provoquer des conditions de concurrence, des problèmes de visibilité et des erreurs de synchronisation difficiles à déboguer.

Solution :

Le JMM définit des règles : quand les modifications apportées par un thread deviennent visibles pour les autres. Il établit des concepts de happens-before, de synchronisateurs (synchronized, volatile, final), de verrouillages internes et limite la réorganisation des instructions dans un environnement multi-thread.

Exemple de code :

class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public synchronized int get() {
        return count;
    }
}

Caractéristiques clés :

Le JMM définit quand les modifications d'une variable sont visibles par d'autres threads
L'utilisation de synchronized ou volatile garantit une publication correcte des modifications
Une utilisation incorrecte peut entraîner un fonctionnement incorrect même en l'absence d'erreurs explicites

Questions pièges.

Pourquoi volatile ne rend-il pas les opérations atomiques, mais garantit seulement la visibilité ?

Volatile garantit uniquement la visibilité des modifications entre les threads, mais pas l'atomicité du changement. Par exemple, l'incrémentation d'une variable volatile n'est pas une opération atomique, car l'action elle-même consiste à lire, modifier et écrire.

Exemple de code :

volatile int count = 0;
count++; // Pas atomique !

Un bloc synchronized peut-il garantir la visibilité des modifications en dehors de celui-ci ?

Oui. Après avoir quitté un bloc synchronized, toutes les modifications apportées à l'intérieur sont visibles par d'autres threads qui entreront dans le bloc sur le même objet-moniteur.

Quand les modifications des champs final deviennent-elles visibles pour d'autres threads ?

Les champs final garantissent une publication correcte uniquement si l'objet est complètement construit avant que des références à celui-ci ne soient transmises à d'autres threads, par exemple, via des objets immuables. Sinon, il peut y avoir une visibilité d'état non initialisé.

Erreurs typiques et anti-patterns

Utiliser la multithreading sans synchronisation sur des variables partagées entre les threads
Compter uniquement sur volatile pour des opérations complexes
Publier des objets non formés entre les threads

Exemple de la vie réelle

Cas négatif

Un développeur a décidé d'augmenter le compteur d'accès au site avec un simple incrément volatile depuis plusieurs threads.

Avantages :

Plus simple, pas besoin de se soucier de synchronized

Inconvénients :

Perte réelle d'incréments sous forte charge en raison de l'absence d'atomicité
Condition de course et statistiques incorrectes

Cas positif

Utilisation d'AtomicInteger pour le compteur ou de méthodes synchronized.