Explication détaillée de l'utilisation du volatile et analyse de ses principes

1. Le rôle du volatile

Dans l'article "Java Concurrent Programming: Core Theory", nous avons déjà évoqué les problèmes de visibilité, d'ordre et d'atomicité. utilisez le mot-clé Synchronized pour résoudre ces problèmes. Cependant, si vous comprenez le principe de Synchronized, vous devez savoir que Synchronized est une opération relativement lourde et a un impact relativement important sur les performances du système. Par conséquent, s'il existe d'autres solutions, nous évitons généralement d'utiliser Synchronized pour résoudre des problèmes. Le mot clé volatile est une autre solution proposée en Java pour résoudre le problème de visibilité et de classement. Concernant l'atomicité, une chose doit être soulignée, et c'est aussi un point qui est facile à mal comprendre : une seule opération de lecture/écriture sur des variables volatiles peut garantir l'atomicité, comme les variables de type long et double, mais elle ne garantit pas l'atomicité. d'opérations telles que i++ Parce qu'essentiellement i++ est une opération en deux temps de lecture et d'écriture.

2. L'utilisation de volatile

Concernant l'utilisation de volatile, nous pouvons utiliser plusieurs exemples pour illustrer son utilisation et ses scénarios.

1. Empêcher les réorganisations

Nous analysons le problème de réorganisation à partir de l'exemple le plus classique. Tout le monde devrait être familier avec l'implémentation du modèle singleton.Pour implémenter un singleton dans un environnement concurrent, nous pouvons généralement utiliser le verrouillage à double vérification (DCL). Le code source est le suivant :

 1 package com.paddx.test.concurrent;
 2 
 3 public class Singleton {
 4     public static volatile Singleton singleton;
 5 
 6     /**
 7      * 构造函数私有，禁止外部实例化
 8      */
 9     private Singleton() {};
10 
11     public static Singleton getInstance() {
12         if (singleton == null) {
13             synchronized (singleton) {
14                 if (singleton == null) {
15                     singleton = new Singleton();
16                 }
17             }
18         }
19         return singleton;
20     }
21 }

Analysons maintenant pourquoi nous devons ajouter le mot-clé volatile entre les variables singleton. Pour comprendre ce problème, vous devez d'abord comprendre le processus de construction d'un objet. L'instanciation d'un objet peut en fait être divisée en trois étapes :

(1) Allouer de l'espace mémoire.

　 (2) Initialisez l'objet.

(3) Attribuez l'adresse de l'espace mémoire à la référence correspondante.

Mais puisque le système d'exploitation peut réorganiser les instructions, le processus ci-dessus peut également devenir le processus suivant :

　 (1) Allouer de l'espace mémoire.

(2) Attribuez l'adresse de l'espace mémoire à la référence correspondante.

　 (3) Initialisation de l'objet

Si tel est le processus, une référence d'objet non initialisée peut être exposée dans un environnement multithread, conduisant à des résultats imprévisibles. Par conséquent, afin d'éviter une réorganisation de ce processus, nous devons définir la variable sur une variable de type volatile.

2. Implémenter la visibilité

　Le problème de visibilité signifie principalement qu'un thread modifie la valeur de la variable partagée, mais un autre thread ne peut pas la voir. La principale raison du problème de visibilité est que chaque thread possède sa propre mémoire de travail de zone de cache. Le mot-clé volatile peut résoudre efficacement ce problème. Jetons un coup d'œil à l'exemple suivant pour voir son effet :

 1 package com.paddx.test.concurrent;
 2 
 3 public class VolatileTest {
 4     int a = 1;
 5     int b = 2;
 6 
 7     public void change(){
 8         a = 3;
 9         b = a;
10     }
11 
12     public void print(){
13         System.out.println("b="+b+";a="+a);
14     }
15 
16     public static void main(String[] args) {
17         while (true){
18             final VolatileTest test = new VolatileTest();
19             new Thread(new Runnable() {
20                 @Override
21                 public void run() {
22                     try {
23                         Thread.sleep(10);
24                     } catch (InterruptedException e) {
25                         e.printStackTrace();
26                     }
27                     test.change();
28                 }
29             }).start();
30 
31             new Thread(new Runnable() {
32                 @Override
33                 public void run() {
34                     try {
35                         Thread.sleep(10);
36                     } catch (InterruptedException e) {
37                         e.printStackTrace();
38                     }
39                     test.print();
40                 }
41             }).start();
42 
43         }
44     }
45 }

　　直观上说，这段代码的结果只可能有两种：b=3;a=3 或 b=2;a=1。不过运行上面的代码（可能时间上要长一点），你会发现除了上两种结果之外，还出现了第三种结果：

...... 
b=2;a=1
b=2;a=1
b=3;a=3
b=3;a=3
b=3;a=1
b=3;a=3
b=2;a=1
b=3;a=3
b=3;a=3
......

　　为什么会出现b=3;a=1这种结果呢？正常情况下，如果先执行change方法，再执行print方法，输出结果应该为b=3;a=3。相反，如果先执行的print方法，再执行change方法，结果应该是 b=2;a=1。那b=3;a=1的结果是怎么出来的？原因就是第一个线程将值a=3修改后，但是对第二个线程是不可见的，所以才出现这一结果。如果将a和b都改成volatile类型的变量再执行，则再也不会出现b=3;a=1的结果了。

3、保证原子性

 　　关于原子性的问题，上面已经解释过。volatile只能保证对单次读/写的原子性。这个问题可以看下JLS中的描述：

17.7 Non-Atomic Treatment of double and long

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.

Writes and reads of volatile long and double values are always atomic.

Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values.

Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32-bit values. For efficiency's sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and double values atomically or in two parts.

Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

　　这段话的内容跟我前面的描述内容大致类似。因为long和double两种数据类型的操作可分为高32位和低32位两部分，因此普通的long或double类型读/写可能不是原子的。因此，鼓励大家将共享的long和double变量设置为volatile类型，这样能保证任何情况下对long和double的单次读/写操作都具有原子性。

　　关于volatile变量对原子性保证，有一个问题容易被误解。现在我们就通过下列程序来演示一下这个问题：

 1 package com.paddx.test.concurrent;
 2 
 3 public class VolatileTest01 {
 4     volatile int i;
 5 
 6     public void addI(){
 7         i++;
 8     }
 9 
10     public static void main(String[] args) throws InterruptedException {
11         final  VolatileTest01 test01 = new VolatileTest01();
12         for (int n = 0; n <div class="cnblogs_code_toolbar"><span class="cnblogs_code_copy"><img src="https://img.php.cn/upload/article/000/000/001/0313942818f37f12b8713dd37831b872-5.gif" alt="Explication détaillée de lutilisation du volatile et analyse de ses principes"></span></div>

Vous pouvez penser à tort qu'après avoir ajouté le mot-clé volatile à la variable i, ce programme est thread-safe. Vous pouvez essayer d'exécuter le programme ci-dessus. Voici le résultat de mon opération locale :

Le résultat peut être différent pour chacun. Cependant, il faut bien voir que volatile ne peut pas garantir l'atomicité (sinon le résultat devrait être 1000). La raison est également très simple. i++ est en fait une opération composée, comprenant trois étapes :

(1) Lire la valeur de i.

(2) Ajoutez 1 à i.

(3) Écrivez la valeur de i dans la mémoire.

Volatile ne peut pas garantir que ces trois opérations sont atomiques. Nous pouvons utiliser AtomicInteger ou Synchronized pour garantir l'atomicité de l'opération +1.

Remarque : la méthode Thread.sleep() est exécutée à de nombreux endroits dans le code ci-dessus. Le but est d'augmenter la probabilité de problèmes de concurrence et n'a aucun autre effet.

3. Le principe du volatile

À travers les exemples ci-dessus, nous devrions essentiellement savoir ce qu'est le volatile et comment l'utiliser. Voyons maintenant comment la couche volatile sous-jacente est implémentée.

　1. Implémentation de la visibilité :

Comme mentionné dans l'article précédent, le thread lui-même n'interagit pas directement avec la mémoire principale, mais via la mémoire de travail. terminer l’opération correspondante. C'est aussi la raison essentielle pour laquelle les données entre les threads sont invisibles. Par conséquent, pour obtenir la visibilité des variables volatiles, commencez simplement par cet aspect. Il existe deux différences principales entre les opérations d'écriture sur des variables volatiles et des variables ordinaires :

(1) Lorsqu'une variable volatile est modifiée, la valeur modifiée sera forcée d'être rafraîchie dans la mémoire principale.

(2) La modification de variables volatiles rendra invalides les valeurs de variables correspondantes dans la mémoire de travail des autres threads. Par conséquent, lorsque vous lisez la valeur de la variable, vous devez relire la valeur dans la mémoire principale.

Grâce à ces deux opérations, le problème de visibilité des variables volatiles peut être résolu.

2. Implémentation ordonnée :

Avant d'expliquer ce problème, comprenons d'abord les règles qui se produisent avant en Java. La règle Happen-before dans JSR 133 La définition de. before est le suivant :

Deux actions peuvent être ordonnées par une relation arrive-avant. Si une action se produit avant une autre, alors la première est visible et ordonnée avant la seconde.

Être. plus populaire Autrement dit, si a se produit avant b, alors toute opération effectuée par a est visible par b. (Tout le monde doit s'en souvenir, car le mot « arrivé avant » est facilement compris à tort comme signifiant avant et après le temps). Jetons un coup d'œil à ce qui se passe avant que les règles soient définies dans JSR 133 :

• Chaque action dans un fil de discussion se produit avant chaque action suivante dans ce fil de discussion
• Un déverrouillage sur un moniteur se produit avant chaque action suivante. verrouiller sur ce moniteur.
• Une écriture dans un champ volatile se produit avant chaque lecture ultérieure de ce volatile
• Un appel à start() sur un thread se produit avant toute action dans le thread démarré. Toutes les actions dans un thread se produisent avant qu'un autre thread ne revienne avec succès d'un join() sur ce thread
• Si une action a se produit avant une action b et que b se produit avant une action c, alors a se produit avant c.

Traduit par :

• Dans le même fil de discussion, l'opération précédente se produit avant l'opération suivante. (C'est-à-dire que le code est exécuté dans l'ordre au sein d'un seul thread. Cependant, le compilateur et le processeur peuvent réorganiser sans affecter les résultats de l'exécution dans un environnement monothread, ce qui est légal. En d'autres termes, cette règle ne peut pas garantir le réarrangement de la compilation et réarrangement des instructions).

• L'opération de déverrouillage sur le moniteur se produit avant son opération de verrouillage ultérieure. (Règles synchronisées)

• Les opérations d'écriture sur les variables volatiles se produisent avant les opérations de lecture ultérieures. (règle volatile)

• La méthode start() d'un thread se produit avant toutes les opérations ultérieures du thread. (Règles de démarrage du fil)

• Toutes les opérations d'un fil se produisent avant que d'autres fils n'appellent join sur ce fil et reviennent avec succès.

• Si a arrive avant b, b arrive avant c, alors a arrive avant c (transitif).

Ici, nous examinons principalement la troisième règle : les règles permettant d'assurer l'ordre des variables volatiles. L'article "Java Concurrent Programming: Core Theory" mentionne que la réorganisation est divisée en réorganisation du compilateur et réorganisation du processeur. Afin d'obtenir une sémantique de mémoire volatile, JMM limitera ces deux types de réorganisation des variables volatiles. Ce qui suit est un tableau des règles de réorganisation spécifiées par JMM pour les variables volatiles :

Can Reorder	2nd operation
1st operation	Normal Load Normal Store	Volatile Load	Volatile Store
Normal Load Normal Store			No
Volatile Load	No	No	No
Volatile store		No	No

　　3、内存屏障

　　为了实现volatile可见性和happen-befor的语义。JVM底层是通过一个叫做“内存屏障”的东西来完成。内存屏障，也叫做内存栅栏，是一组处理器指令，用于实现对内存操作的顺序限制。下面是完成上述规则所要求的内存屏障：

Required barriers	2nd operation
1st operation	Normal Load	Normal Store	Volatile Load	Volatile Store
Normal Load				LoadStore
Normal Store				StoreStore
Volatile Load	LoadLoad	LoadStore	LoadLoad	LoadStore
Volatile Store			StoreLoad	StoreStore

（1）LoadLoad 屏障
执行顺序：Load1—>Loadload—>Load2
确保Load2及后续Load指令加载数据之前能访问到Load1加载的数据。

（2）StoreStore 屏障
执行顺序：Store1—>StoreStore—>Store2
确保Store2以及后续Store指令执行前，Store1操作的数据对其它处理器可见。

（3）LoadStore 屏障
执行顺序： Load1—>LoadStore—>Store2
确保Store2和后续Store指令执行前，可以访问到Load1加载的数据。

（4）StoreLoad 屏障
执行顺序: Store1—> StoreLoad—>Load2
确保Load2和后续的Load指令读取之前，Store1的数据对其他处理器是可见的。

最后我可以通过一个实例来说明一下JVM中是如何插入内存屏障的：

 1 package com.paddx.test.concurrent;
 2 
 3 public class MemoryBarrier {
 4     int a, b;
 5     volatile int v, u;
 6 
 7     void f() {
 8         int i, j;
 9 
10         i = a;
11         j = b;
12         i = v;
13         //LoadLoad
14         j = u;
15         //LoadStore
16         a = i;
17         b = j;
18         //StoreStore
19         v = i;
20         //StoreStore
21         u = j;
22         //StoreLoad
23         i = u;
24         //LoadLoad
25         //LoadStore
26         j = b;
27         a = i;
28     }
29 }

四、总结

　　总体上来说volatile的理解还是比较困难的，如果不是特别理解，也不用急，完全理解需要一个过程，在后续的文章中也还会多次看到volatile的使用场景。这里暂且对volatile的基础知识和原来有一个基本的了解。总体来说，volatile是并发编程中的一种优化，在某些场景下可以代替Synchronized。但是，volatile的不能完全取代Synchronized的位置，只有在一些特殊的场景下，才能适用volatile。总的来说，必须同时满足下面两个条件才能保证在并发环境的线程安全：

　　（1）对变量的写操作不依赖于当前值。

　　（2）该变量没有包含在具有其他变量的不变式中。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!