So lösen Sie das Double-Check-Lock-Problem in Java

Der Ursprung der Doppelprüfsperre

Werfen wir zunächst einen Blick auf den nicht-threadsicheren Initialisierungs-Singleton-Modus

	public class UnsafeLazyInitialization {
		private static UnsafeLazyInitialization instance;

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

Angenommen, in der UnsafeLazyInitialization-Klasse wird davon ausgegangen, dass Thread B Code 2 ausführt, wenn Thread A Code 1 ausführt Zeit Thread A kann feststellen, dass das Instanzreferenzobjekt noch nicht initialisiert wurde.

Für die UnsafeLazyInitialization-Klasse können wir die getInstance()-Methode synchronisieren, um eine threadsichere verzögerte Initialisierung zu erreichen. Der Beispielcode lautet wie folgt:

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

Da der obige Code die getInstance()-Methode synchronisiert, kann dies zu einer Synchronisierung des Programms führen Der Overhead steigt. Wenn getInstance() häufig von mehreren Threads aufgerufen wird, wird die Leistung der Programmausführung verringert. Wenn es jedoch nicht von mehreren Threads aufgerufen wird, wirkt sich die verzögerte Initialisierungsmethode der getInstance()-Methode auf die Leistung aus.

Vor JVM 1.6 war die Synchronisierung eine Schwergewichtssperre, daher war sie sehr leistungsintensiv. Daher dachten die Leute über eine Lösung mit Doppelprüfungssperre (Dobule-Check Locking) nach, um die Leistung zu verbessern. Der Beispielcode lautet wie folgt:

	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;
		}
	}

Wie im obigen Code gezeigt: Wenn die erste Prüfung in Schritt 4 nicht null ist, muss der folgende Sperrvorgang nicht ausgeführt werden, wodurch die durch synchronisierte Sperren verursachten Leistungsprobleme erheblich reduziert werden. Es scheint kein Problem mit dem obigen Code zu geben. 1. Wenn mehrere Thread-Ansichten neue Objekte erstellen, kann das synchronisierte Schlüsselwort verwendet werden, um sicherzustellen, dass nur ein Thread das Objekt erfolgreich erstellt.

2. Wenn das Instanzobjekt erstellt wurde, rufen Sie die Objektinstanz direkt über die Methode getInstatnce() ab.

Überprüfen Sie das Sperrproblem oben noch einmal

Der obige Code sieht perfekt aus, aber wenn Schritt 4 ausgeführt wird, instatnce! =null, das Referenzobjekt der Instanz ist möglicherweise noch nicht initialisiert.

Die Wurzel des Problems

Wenn wir den obigen Code bis Schritt 7 ausführen, Instanz = neue Instanz();, wird ein Objekt erstellt. Dieser Schritt zum Erstellen eines Objekts kann wie folgt in drei Schritte unterteilt werden:

rrree

Die oben genannten drei Codezeilen 2 und 3 können neu angeordnet werden (Auf dem JTI-Compiler geschieht diese Neuordnung tatsächlich) Die Ausführungssequenz nach der Neuordnung der Schritte 2 und 3

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

Werfen wir einen Blick auf die Multithread-Ausführungssequenz

Instance = new Instance() in Zeile 7 des obigen Codes; Wenn Thread A eine Neuordnung der Anweisung (2,3) vornimmt, stellt ein anderer Thread B möglicherweise fest, dass die Instanz in Zeile 4 des Codes nicht leer ist Code. Thread B greift als nächstes auf das Referenzobjekt der Instanz zu, das Instanzobjekt wurde jedoch möglicherweise nicht von A initialisiert. Zu diesem Zeitpunkt greift Thread B möglicherweise auf ein Objekt zu, das nicht initialisiert wurde, was zu einem Nullzeigerfehler führt.

Problem gelöst

1. Befehlsumordnung von 2 und 3 ist nicht zulässig. 2. Erlauben Sie die Neuordnung von 2 und 3, aber lassen Sie nicht zu, dass andere Threads die Neuordnung sehen unten

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

Das obige ist der detaillierte Inhalt vonSo lösen Sie das Double-Check-Lock-Problem in Java. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!