Comment résoudre le problème de verrouillage à double vérification en Java

L'origine du verrouillage à double vérification

Tout d'abord, jetons un coup d'œil au mode singleton d'initialisation non thread-safe

	public class UnsafeLazyInitialization {
		private static UnsafeLazyInitialization instance;

		public static UnsafeLazyInitialization getInstance(){
			if(instance == null){                           //1:  线程A执行
				instance = new UnsafeLazyInitialization();  //2： 线程B执行
			}
			return instance;
		}
	}

Dans la classe UnsafeLazyInitialization, supposons que lorsque le thread A exécute le code 1, le thread B exécute le code 2, à ce le thread temporel A peut voir que l'objet de référence d'instance n'a pas encore été initialisé.

Pour la classe UnsafeLazyInitialization, nous pouvons synchroniser la méthode getInstance() pour obtenir une initialisation retardée sécurisée pour les threads. L'exemple de code est le suivant :

	public static synchronized  UnsafeLazyInitialization getInstance(){
			if(instance == null){                           //1:  线程A执行
				instance = new UnsafeLazyInitialization();  //2： 线程B执行
			}
			return instance;
		}
	}

Étant donné que le code ci-dessus synchronise la méthode getInstance(), cela peut conduire à une synchronisation du programme. les frais généraux augmentent. Si getInstance() est fréquemment appelé par plusieurs threads, les performances d'exécution du programme seront réduites. Au contraire, s'il n'est pas appelé par plusieurs threads, la méthode d'initialisation retardée de la méthode getInstance() affectera les performances.

Avant JVM 1.6, synchronisé était un verrou lourd, donc très gourmand en performances, les gens ont donc pensé à une solution de verrouillage à double vérification (Dobule-check Locking) pour améliorer les performances. L'exemple de code est le suivant :

	public class DoubleCheckedLocking {                                 //1、
		private static Instance instance;                               //2、
		public static Instance getInstance(){                          //3、
			if(instance == null){                                      //4、第一次检查
				synchronized (DoubleCheckedLocking.class){              //5、枷锁
					if(instance == null){                                //6、第二次检查
						instance = new Instance();                       //7、问题的根源在这里
					}                                                    //8、
				}
			}
			return instance;
		}
	}

. Comme le montre le code ci-dessus : si la première vérification à l'étape 4 n'est pas nulle, il n'est alors pas nécessaire d'effectuer l'opération de verrouillage suivante, ce qui réduit considérablement les problèmes de performances causés par les verrous synchronisés. Il ne semble y avoir aucun problème avec le code ci-dessus. 1. Lorsque plusieurs vues de thread créent de nouveaux objets, le mot-clé synchronisé peut être utilisé pour garantir qu'un seul thread crée correctement l'objet.

2. Si l'objet instance a été créé, obtenez l'instance d'objet directement via la méthode getInstatnce().

Vérifiez à nouveau le problème de verrouillage ci-dessus

Le code ci-dessus semble parfait, mais lorsque l'étape 4 est exécutée, instantané ! =null, l'objet de référence de l'instance n'est peut-être pas encore initialisé.

La racine du problème

Lorsque nous exécutons le code ci-dessus à l'étape 7, instance = new Instance();, un objet est créé. Cette étape de création d'un objet peut être divisée en trois étapes, comme suit :

	memory = allocate()  //1.分配内存空间memory
	ctorInstance(memory) //2, 初始化对象在内存 分配内存空间memory上初始化 Singleton 对象
	instance = memory //3、设置 instance 指向刚分配的内存地址memory

.

Les trois lignes de code 2 et 3 ci-dessus peuvent être réorganisées. (Sur le compilateur JTI, cette réorganisation se produit réellement) La séquence d'exécution après la réorganisation des étapes 2 et 3

	memory = allocate()  //1.分配内存空间memory
	instance = memory //3、设置 instance 指向刚分配的内存地址memory
									// 注意此时instance对象还没有被初始化，但是instance的引用已经不是null了。
	ctorInstance(memory) //2, 初始化对象在内存 分配内存空间memory上初始化 Singleton 对象

Jetons un coup d'œil à la séquence d'exécution multi-thread.

Instance = new Instance() à la ligne 7 du code ci-dessus ; Si le thread A se produit dans la réorganisation des instructions (2,3), alors un autre thread B peut déterminer que l'instance n'est pas vide à la ligne 4 du code. Le thread B accède ensuite à l'objet de référence de l'instance, mais l'objet d'instance n'a peut-être pas été initialisé par A. À ce stade, le thread B peut accéder à un objet qui n'a pas été initialisé, ce qui entraîne une erreur de pointeur nul.

Problème résolu

1. Le réarrangement des commandes de 2 et 3 n'est pas autorisé. 2. Autorisez la réorganisation de 2 et 3, mais ne permettez pas aux autres threads de voir la réorganisation

Une solution basée sur la volatilité

Sur la base du code ci-dessus, il vous suffit d'ajouter le mot-clé volatile à la déclaration d'instance, comme indiqué ci-dessous

	public class DoubleCheckedLocking {                                 //1、
		private static volatile Instance instance;                               //2、
		public static Instance getInstance(){                          //3、
			if(instance == null){                                      //4、第一次检查
				synchronized (DoubleCheckedLocking.class){              //5、枷锁
					if(instance == null){                                //6、第二次检查
						instance = new Instance();                       //7、问题的根源在这里
					}                                                    //8、
				}
			}
			return instance;
		}
	}

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!