[Lutte contre la concurrence Java]-----Analyse du modèle de mémoire Java volatile

Les caractéristiques de volatile ont déjà été expliquées dans le blog précédent [Fuck Java Concurrency] - Analyse approfondie du principe d'implémentation de volatile :

1. visibilité volatile ; pour a Pour les lectures volatiles, vous pouvez toujours voir l'écriture finale dans cette variable

2. l'atomicité volatile est atomique pour une seule lecture/écriture (32 bits Long, Double), Mais composite Sauf pour les opérations telles que i La sémantique de la mémoire de volatile introduit volatile dans deux directions.

volatile et se produit avant

3. Dans ce blog [Deadly Java Concurrency] - Java Memory Model Happend-Before, LZ explique que ce qui se passe avant est utilisé pour déterminer si les données sont stockées. La base de la compétition et de la sécurité des threads est d'assurer la visibilité dans un environnement multithread. Prenons l'exemple classique pour analyser la relation événement-avant établie par la lecture et l'écriture de variables volatiles.

Selon le principe de l'ordre des programmes qui se produit avant, la relation suivante est obtenue pour le programme ci-dessus :

Selon le principe de l'ordre du programme qui se produit avant : 1 arrive-avant 2, 3 arrive -avant 4

public class VolatileTest {

    int i = 0;    volatile boolean flag = false;    //Thread A
    public void write(){
        i = 2;              //1
        flag = true;        //2
    }    //Thread B
    public void read(){        if(flag){                                   //3
            System.out.println("---i = " + i);      //4
        }
    }
}

Selon le principe volatile de arrive-avant : 2 arrive-avant 3; >Selon la transitivité de arrive-avant : 1 arrive-avant 4

• L'opération 1 et l'opération 4 ont une relation arrive-avant, donc 1 doit être visible par 4. Certains étudiants peuvent demander, l'opération 1 et l'opération 2 peuvent être réorganisées, est-ce possible ? Si vous avez lu le blog de LZ, vous comprendrez qu'en plus d'assurer la visibilité, volatile interdit également les réorganisations. Par conséquent, toutes les variables partagées visibles par le thread A avant d'écrire la variable volatile deviendront visibles par le thread B immédiatement après que le thread B ait lu la même variable volatile.

Sémantique de la mémoire et implémentation de volatile

• Dans JMM, la communication entre les threads est implémentée à l'aide de la mémoire partagée. La sémantique mémoire de volatile est :

• Lors de l'écriture d'une variable volatile, JMM actualisera immédiatement la valeur de la variable partagée dans la mémoire locale correspondant au thread vers la mémoire principale.

  Lors de la lecture d'une variable volatile, JMM définira la mémoire locale correspondant au thread comme invalide et lira la variable partagée directement à partir de la mémoire principale

Par conséquent, la sémantique de la mémoire d'écriture de volatile est directement actualisée. la mémoire principale, la sémantique de lecture de la mémoire consiste à lire directement à partir de la mémoire principale.

Alors, comment la sémantique de la mémoire volatile est-elle implémentée ? Pour les variables générales, elles seront réorganisées, mais pour les variables volatiles, elles ne seront pas réorganisées. Cela affectera la sémantique de la mémoire, donc afin d'obtenir une sémantique de la mémoire volatile, JMM limitera la réorganisation. Les règles de réorganisation sont les suivantes :

se traduit comme suit :

Si la première opération est une lecture volatile, quelle que soit la deuxième opération, elle ne peut pas être réorganisé. Cette opération garantit que les opérations après la lecture volatile ne seront pas réorganisées par le compilateur avant la lecture volatile

Lorsque la deuxième opération est une écriture volatile, quelle que soit la première opération ; , Ni l'un ni l'autre ne peut être récommandé. Cette opération garantit que les opérations avant l'écriture volatile ne seront pas réorganisées par le compilateur après l'écriture volatile

Lorsque la première opération est une écriture volatile et la deuxième opération est une lecture volatile, elle ne peut pas l'être ; réorganisé.

1. L'implémentation sous-jacente de volatile consiste à insérer des barrières de mémoire, mais il est presque impossible pour le compilateur de trouver un arrangement optimal qui minimise le nombre total de barrières de mémoire insérées, donc JMM adopte une stratégie conservatrice. Comme suit :

2. Insérez une barrière StoreStore avant chaque opération d'écriture volatile

3. Insérez une barrière StoreLoad après chaque opération d'écriture volatile

Insérez une barrière LoadLoad après chaque opération de lecture volatile

• Insérez une barrière LoadStore après chaque opération de lecture volatile

• StoreStore La barrière peut garantir que toutes les opérations d'écriture ordinaires devant elle ont été vidées dans la mémoire principale avant l'écriture volatile.

Le but de la barrière StoreLoad est d'empêcher les écritures volatiles d'être réorganisées par des opérations de lecture/écriture volatiles ultérieures.

• La barrière LoadLoad est utilisée pour empêcher le processeur de réorganiser les lectures volatiles ci-dessus et les lectures normales ci-dessous.

La barrière LoadStore est utilisée pour empêcher le processeur de réorganiser les lectures volatiles ci-dessus et les écritures ordinaires ci-dessous.

• Analysons l'exemple VolatileTest ci-dessus :

La légende de la barrière mémoire de l'instruction volatile est légèrement démontrée à travers un exemple.

La stratégie d'insertion de barrières de mémoire volatile est très conservatrice. En fait, en pratique, tant que la sémantique de la mémoire volatile en écriture-lecture n'est pas modifiée, le compilateur peut optimiser en fonction de la situation spécifique et omettre les barrières inutiles. Comme suit (extrait de « The Art of Java Concurrent Programming » de Fang Tengfei) :

L'exemple d'image sans optimisation est le suivant :

public class VolatileTest {
    int i = 0;    
    volatile boolean flag = false;    
    public void write(){
        i = 2;
        flag = true;
    }    public void read(){        
    if(flag){
            System.out.println("---i = " + i); 
        }
    }
}

Analysons l'image ci-dessus Quelles instructions de barrière mémoire sont redondantes

1

: Celle-ci doit être conservée

2 : Il est interdit à toutes les écritures normales ci-dessous d'être réorganisées avec les lectures volatiles ci-dessus. Cependant, en raison de l'existence d'une deuxième lecture volatile, la lecture normale ne peut pas du tout contourner la deuxième lecture volatile. On peut donc l'omettre.

3 : Il n'y a pas de lecture normale ci-dessous et peut être omis.

4 : réservé

5 : réservé

6 : suivi d'une écriture volatile, Donc

7 peut être omis : gardez

8 : gardez

donc 2, 3 et 6 peuvent être omis, son diagramme schématique Comme suit :

Ce qui précède est le contenu de [Deadly Java Concurrency] -----Analyse de la mémoire Java Model Volatile, plus Pour le contenu associé, veuillez faire attention au site Web PHP chinois (www.php.cn) !