Avant-propos :
Il existe de nombreuses façons d'implémenter le mode singleton, telles que le mode faim, le mode paresseux, les classes internes et les énumérations statiques, etc. Lorsque l'intervieweur a demandé « Pourquoi le mode singleton doit-il être ajouté ? " volatile ? ", alors il fait référence à la raison pour laquelle les variables privées en mode paresseux doivent être volatiles ?
Le mode paresseux fait référence à la méthode de chargement paresseux de création d'objet. L'objet n'est pas créé au démarrage du programme, mais est créé uniquement lorsqu'il est réellement utilisé pour la première fois.
Besoin d'expliquer pourquoi du volatile est ajouté ? Examinons d'abord le code d'implémentation spécifique du mode paresseux :
public class Singleton { // 1.防止外部直接 new 对象破坏单例模式 private Singleton() {} // 2.通过私有变量保存单例对象【添加了 volatile 修饰】 private static volatile Singleton instance = null; // 3.提供公共获取单例对象的方法 public static Singleton getInstance() { if (instance == null) { // 第 1 次效验 synchronized (Singleton.class) { if (instance == null) { // 第 2 次效验 instance = new Singleton(); } } } return instance; } }
Comme le montre le code ci-dessus, afin de garantir la sécurité des threads et des performances élevées, if et synchronisé sont utilisés deux fois dans le code pour assurer l'exécution du programme. Donc, puisqu'il y a déjà une synchronisation pour garantir la sécurité des threads, pourquoi devons-nous ajouter volatile à la variable ? Avant d’expliquer ce problème, il faut d’abord comprendre une connaissance préalable : à quoi sert volatile ?
volatile a deux fonctions principales : premièrement, elle résout le problème de visibilité de la mémoire et deuxièmement, elle empêche la réorganisation des instructions.
Le soi-disant problème de visibilité de la mémoire fait référence au fait que plusieurs threads exploitent une variable en même temps après qu'un thread ait modifié la valeur de la variable, les autres threads ne peuvent pas percevoir la modification de la variable. . Il s'agit de problèmes de visibilité de la mémoire. L'utilisation de volatile peut résoudre le problème de visibilité de la mémoire Par exemple, le code suivant, lorsque volatile n'est pas ajouté, son implémentation est la suivante :
private static boolean flag = false; public static void main(String[] args) { Thread t1 = new Thread(new Runnable() { @Override public void run() { // 如果 flag 变量为 true 就终止执行 while (!flag) { } System.out.println("终止执行"); } }); t1.start(); // 1s 之后将 flag 变量的值修改为 true Thread t2 = new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("设置 flag 变量的值为 true!"); flag = true; } }); t2.start(); }
Les résultats d'exécution du programme ci-dessus sont les suivants :
.
Cependant, le programme ci-dessus Après avoir été exécuté N fois longtemps, l'exécution n'est toujours pas terminée, ce qui signifie qu'après que le thread 2 a modifié la variable flag, le thread 1 n'a pas du tout perçu la modification de la variable.
Ensuite, nous essayons d'ajouter volatile au drapeau. Le code d'implémentation est le suivant :
public class volatileTest { private static volatile boolean flag = false; public static void main(String[] args) { Thread t1 = new Thread(new Runnable() { @Override public void run() { // 如果 flag 变量为 true 就终止执行 while (!flag) { } System.out.println("终止执行"); } }); t1.start(); // 1s 之后将 flag 变量的值修改为 true Thread t2 = new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("设置 flag 变量的值为 true!"); flag = true; } }); t2.start(); } }
Les résultats d'exécution du programme ci-dessus sont les suivants :
À partir des résultats d'exécution ci-dessus, nous pouvons voir qu'après avoir utilisé volatile Il est possible de résoudre le problème de visibilité de la mémoire dans le programme.
La réorganisation des instructions signifie que pendant l'exécution du programme, le compilateur ou la JVM réorganise souvent les instructions pour améliorer les performances d'exécution du programme. L'intention de conception originale de la réorganisation des instructions est en effet très bonne, et elle peut également jouer un grand rôle dans un seul thread. Cependant, dans les multi-threads, l'utilisation de la réorganisation des instructions peut entraîner des problèmes de sécurité des threads.
Le problème dit de sécurité des threads signifie que le résultat de l'exécution du programme ne correspond pas à nos attentes. Par exemple, si le résultat correct attendu est 0, mais que le résultat de l’exécution du programme est 1, il s’agit alors d’un problème de sécurité des threads.
L'utilisation de volatile peut interdire la réorganisation des instructions, garantissant ainsi que le programme peut être exécuté correctement lors de son exécution dans plusieurs threads.
De retour au sujet, nous utilisons volatile en mode singleton, principalement parce que volatile peut interdire la réorganisation des instructions, assurant ainsi le fonctionnement normal du programme. Certains lecteurs peuvent poser des questions ici, la synchronisation n'est-elle pas déjà utilisée pour garantir la sécurité des threads ? Alors pourquoi ajouter du volatile ? Regardez le code ci-dessous :
public class Singleton { private Singleton() {} // 使用 volatile 禁止指令重排序 private static volatile Singleton instance = null; public static Singleton getInstance() { if (instance == null) { // ① synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); // ② } } } return instance; } }
Faites attention au code ci-dessus, j'ai marqué les deux lignes de code en ① et ②. L'ajout de volatile aux variables privées vise principalement à empêcher la réorganisation des instructions lors de l'exécution de ②, c'est-à-dire l'exécution de "instance = new Singleton()". Cette ligne de code semble être juste un processus de création d'objet, mais c'est réel L'exécution est divisée en 3 étapes suivantes :
Créer de l'espace mémoire.
Initialisez l'objet Singleton dans l'espace mémoire.
Attribuez l'adresse mémoire à l'objet instance (après avoir exécuté cette étape, l'instance ne sera pas égale à null).
Imaginez, Si volatile n'est pas ajouté, alors le thread 1 peut effectuer une réorganisation des instructions lors de l'exécution du ② du code ci-dessus, et l'ordre d'exécution d'origine de 1, 2 et 3 sera réorganisé en 1, 3 , 2. Mais dans des circonstances particulières, après que le thread 1 a exécuté l'étape 3, si le thread 2 vient et exécute la première étape du code ci-dessus, il est jugé que l'objet instance n'est pas nul, mais le thread 1 n'a pas encore fini d'instancier l'objet. Le thread 2 obtiendra un "demi" objet qui est instancié, provoquant une erreur dans l'exécution du programme. C'est pourquoi volatile est ajouté à la variable privée.
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!