Analyse approfondie du modèle de mémoire Java : volatile-javaDidacticiel-php.cn

Caractéristiques de volatile

Quand on déclare une variable partagée comme volatile, la lecture/écriture de cette variable va être très particulière. Un bon moyen de comprendre la nature de volatile est de considérer les lectures/écritures individuelles sur des variables volatiles comme la synchronisation de ces opérations de lecture/écriture individuelles à l'aide du même verrou de moniteur. Illustrons avec un exemple spécifique. Veuillez consulter l'exemple de code suivant :

class VolatileFeaturesExample {
    volatile long vl = 0L;  //使用volatile声明64位的long型变量

    public void set(long l) {
        vl = l;   //单个volatile变量的写
    }

    public void getAndIncrement () {
        vl++;    //复合（多个）volatile变量的读/写
    }

    public long get() {
        return vl;   //单个volatile变量的读
    }
}

Copier après la connexion

Supposons qu'il existe plusieurs threads appelant respectivement les trois méthodes du programme ci-dessus. Ce programme est sémantiquement équivalent au programme suivant :

class VolatileFeaturesExample {
    long vl = 0L;               // 64位的long型普通变量

    public synchronized void set(long l) {     //对单个的普通 变量的写用同一个监视器同步
        vl = l;
    }

    public void getAndIncrement () { //普通方法调用
        long temp = get();           //调用已同步的读方法
        temp += 1L;                  //普通写操作
        set(temp);                   //调用已同步的写方法
    }
    public synchronized long get() { 
    //对单个的普通变量的读用同一个监视器同步
        return vl;
    }
}

Copier après la connexion

Comme le montre l'exemple de programme ci-dessus, une seule opération de lecture/écriture sur une variable volatile utilise le même verrou de moniteur qu'une opération de lecture/écriture sur une variable ordinaire synchronisée. l'effet d'exécution entre eux est le même.

La règle du verrouillage du moniteur garantit la visibilité de la mémoire entre les deux threads qui libèrent le moniteur et acquièrent le moniteur. Cela signifie qu'une lecture d'une variable volatile peut toujours être vue (n'importe quel thread) en écriture finale. à cette variable volatile.

La sémantique des verrous du moniteur détermine que l'exécution du code de la section critique est atomique. Cela signifie que même pour les variables doubles et longues de 64 bits, tant qu'il s'agit d'une variable volatile, la lecture et l'écriture dans la variable seront atomiques. S'il existe plusieurs opérations volatiles ou opérations composites similaires à volatiles, ces opérations ne sont pas atomiques dans leur ensemble.

En bref, les variables volatiles elles-mêmes ont les propriétés suivantes :
Visibilité. Une lecture à partir d'une variable volatile verra toujours la dernière écriture (par n'importe quel thread) dans la variable volatile.
Atomicité : la lecture/écriture d'une variable volatile unique est atomique, mais les opérations composées comme volatile ne sont pas atomiques.

Ce qui se produit avant la relation établie par volatile write-read

Ce qui précède concerne les caractéristiques des variables volatiles elles-mêmes. Pour les programmeurs, volatile a un plus grand impact sur la visibilité de la mémoire des threads que volatile lui-même. . Les fonctionnalités sont plus importantes et nécessitent plus d’attention de notre part.

À partir de JSR-133, la lecture en écriture des variables volatiles permet la communication entre les threads.

Du point de vue de la sémantique de la mémoire, les verrous volatiles et de moniteur ont le même effet : l'écriture volatile et la libération du moniteur ont la même sémantique de mémoire ; la lecture volatile et l'acquisition de moniteur ont la même sémantique de mémoire.

Veuillez consulter l'exemple de code suivant utilisant des variables volatiles :

class VolatileExample {
    int a = 0;
    volatile boolean flag = false;

    public void writer() {
        a = 1;                   //1
        flag = true;               //2
    }

    public void reader() {
        if (flag) {                //3
            int i =  a;           //4
            ……
        }
    }
}

Copier après la connexion

Supposons qu'après que le thread A ait exécuté la méthodewriter(), le thread B exécute la méthode reader(). Selon la règle de l'ordre du programme, la relation qui se produit avant établie dans ce processus peut être divisée en deux catégories :
Selon la règle de l'ordre du programme, 1 se produit avant 2 ; 3 se produit avant 4 ;
Selon les règles volatiles, 2 arrive avant 3.
Selon la règle de transitivité de se produit avant, 1 se produit avant 4.

La représentation graphique de ce qui précède se produit avant la relation est la suivante :