Java verwendet drei Methoden, um Beispielcode für Sperren mit hoher Parallelität zu implementieren

In diesem Artikel werden hauptsächlich drei Arten von Implementierungsbeispielcodes für Sperren mit hoher Parallelität in Java vorgestellt. Der Herausgeber findet ihn recht gut, daher werde ich ihn jetzt mit Ihnen teilen und als Referenz verwenden. Folgen wir dem Herausgeber und werfen wir einen Blick darauf

Grundkenntnisse – Optimistisches Sperren

Optimistisches Sperren eignet sich für solche Szenarien: Es wird keine Konflikte beim Lesen geben, aber es wird welche geben Konflikte beim Schreiben. Die Häufigkeit gleichzeitiger Lesevorgänge ist viel größer als die von Schreibvorgängen.

Nehmen Sie den folgenden Code als Beispiel, die Implementierung einer pessimistischen Sperre:

public Object get(Object key) { 
  synchronized(map) { 
   if(map.get(key) == null) { 
     // set some values 
   } 
    return map.get(key); 
  } 
}

Die Implementierung einer optimistischen Sperre:

public Object get(Object key) { 
  Object val = null; 
  if((val = map.get(key) == null) { 
    // 当map取值为null时再加锁判断 
    synchronized(map) { 
      if(val = map.get(key) == null) { 
        // set some value to map... 
      } 
    } 
  } 
  return map.get(key); 
}

Fortgeschrittene Fähigkeit - String.intern()

Optimistisches Sperren kann eine große Anzahl von Schreibkonflikten nicht sehr gut lösen, aber in vielen Szenarien Die Sperre gilt eigentlich nur für einen bestimmten Benutzer oder eine Bestellung. Beispielsweise muss ein Benutzer zunächst eine Sitzung erstellen, bevor er nachfolgende Vorgänge ausführen kann. Aus Netzwerkgründen kommen die Anforderung zum Erstellen einer Benutzersitzung und nachfolgende Anforderungen jedoch fast gleichzeitig an, und parallele Threads können nachfolgende Anforderungen zuerst verarbeiten. Im Allgemeinen muss die SessionMap des Benutzers gesperrt werden, z. B. die obige optimistische Sperre. In diesem Szenario kann die Sperre auf den Benutzer selbst beschränkt werden, d. h. das ursprüngliche

lock.lock();

  int num=storage.get(key);

  storage.set(key,num+1);

lock.unlock();

wird geändert in:

lock.lock(key);

  int num=storage.get(key);

  storage.set(key,num+1);

lock.unlock(key);

Dies ähnelt dem Konzept der Datenbanktabellensperre und der Zeilensperre. Offensichtlich ist die Parallelitätsfähigkeit der Zeilensperre viel höher als die der Tabellensperre.

Die Verwendung von String.inter() ist eine konkrete Umsetzung dieser Idee. Die Klasse String verwaltet einen Pool von Zeichenfolgen. Wenn die interne Methode aufgerufen wird und der Pool bereits eine Zeichenfolge enthält, die diesem String-Objekt entspricht (wie durch die Methode equal(Object) bestimmt), wird die Zeichenfolge im Pool zurückgegeben. Es ist ersichtlich, dass String.intern () bei gleichen Zeichenfolgen immer dasselbe Objekt zurückgibt, sodass die Sperrung desselben Benutzers erreicht wird. Da die Granularität der Sperre auf bestimmte Benutzer beschränkt ist, erreicht das System maximale Parallelität.

public void doSomeThing(String uid) { 
  synchronized(uid.intern()) { 
    // ... 
  } 
}

CopyOnWriteMap?

Da wir nun über „ein Konzept ähnlich Zeilensperren in einer Datenbank“ sprechen, müssen wir MVCC erwähnen. Die CopyOnWrite-Klasse in Java implementiert MVCC. Copy On Write ist ein solcher Mechanismus. Wenn wir gemeinsam genutzte Daten lesen, lesen wir sie direkt ohne Synchronisierung. Wenn wir die Daten ändern, kopieren wir eine Kopie der aktuellen Daten und ändern sie dann auf dieser Kopie. Nach Abschluss verwenden wir die geänderte Kopie, um die Originaldaten zu ersetzen. Diese Methode wird „Copy On Write“ genannt.

Das JDK bietet jedoch kein CopyOnWriteMap. Warum? Unten finden Sie eine gute Antwort: Wir haben bereits ConcurrentHashMap. Warum benötigen wir CopyOnWriteMap?

Fredrik Bromee hat geschrieben

Ich denke, das hängt von Ihrem Anwendungsfall ab, aber warum sollten Sie eine CopyOnWriteMap benötigen, wenn Sie bereits eine ConcurrentHashMap haben?

Für eine einfache Nachschlagetabelle mit Bei vielen Lesern und nur einem oder wenigen Updates passt es gut.

Im Vergleich zu einer Kopie in der Schreibsammlung:

Parallelität lesen:

Gleich einer Kopie in der Schreibsammlung . Mehrere Leser können Elemente gleichzeitig und ohne Sperre aus der Karte abrufen.

Parallelität beim Schreiben:

Bessere Parallelität als das Kopieren bei Schreibsammlungen, die Aktualisierungen grundsätzlich serialisieren (ein Update nach dem anderen). ). Wenn Sie eine gleichzeitige Hash-Map verwenden, haben Sie gute Chancen, mehrere Aktualisierungen gleichzeitig durchzuführen.

Wenn Sie die Wirkung einer Kopie auf der Write-Map haben möchten, können Sie dies jederzeit tun Initialisieren Sie eine ConcurrentHashMap mit einem Parallelitätsgrad von 1.

Erweiterte Tipps – Der Nachteil der Klasse ConcurrentHashMap

String.inter() besteht darin, dass die Klasse String einen String-Pool verwaltet Wenn die Anzahl der Benutzer im JVM-Perm-Bereich besonders groß ist, ist der im String-Pool platzierte String nicht kontrollierbar, was zu OOM-Fehlern oder übermäßigem Full GC führen kann. Wie können wir die Anzahl der Sperren steuern und die Granularität der Sperren reduzieren? Java ConcurrentHashMap direkt verwenden? Oder möchten Sie Ihre eigene, detailliertere Steuerung hinzufügen? Dann können Sie von ConcurrentHashMap lernen, die zu sperrenden Objekte in mehrere Buckets aufteilen und jedem Bucket eine Sperre hinzufügen. Der Pseudocode lautet wie folgt:

Map locks = new Map(); 
List lockKeys = new List(); 
for(int number : 1 - 10000) { 
  Object lockKey = new Object(); 
  lockKeys.add(lockKey); 
  locks.put(lockKey, new Object()); 
}  
public void doSomeThing(String uid) { 
  Object lockKey = lockKeys.get(uid.hash() % lockKeys.size()); 
  Object lock = locks.get(lockKey); 
  synchronized(lock) { 
   // do something 
  } 
}

Das obige ist der detaillierte Inhalt vonJava verwendet drei Methoden, um Beispielcode für Sperren mit hoher Parallelität zu implementieren. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!