Single Threaded Execution Pattern

Ein Muster, das die Verarbeitung einschränkt, sodass jeweils nur ein Thread ausgeführt werden kann. Das Single Threaded Execution-Muster wird manchmal als ** Kritischer Abschnitt ** oder ** Kritischer Bereich ** bezeichnet.

(Code, der wie beabsichtigt funktioniert und Code, der nicht wie beabsichtigt funktioniert)

Charakter

Im Single Threaded Execution-Muster wird eine Klasse mit der Rolle ** Shared Resourece ** angezeigt. Die SharedResourece-Rolle verfügt über mehrere Methoden, die in die folgenden zwei Typen unterteilt sind.

--safeMethod: Eine Methode, die problemlos von mehreren Threads gleichzeitig aufgerufen werden kann. --unsafeMethod: Eine Methode, die geschützt werden muss, da nicht mehrere Threads gleichzeitig aufrufen können.

Das Single Threaded Execution-Muster schützt unsaMetMethad so, dass jeweils nur ein Thread darauf zugreifen kann. In Java wird das Schützen realisiert, indem es zu einer synchronisierten Methode gemacht wird. Der Bereich, der in einem einzelnen Thread betrieben werden muss, wird als ** kritischer Abschnitt ** bezeichnet.

Wann zu verwenden

Beim Zugriff über mehrere Threads. Wenn auf eine Instanz der SharedResource-Rolle mehrere Threads gleichzeitig zugreifen können. Nicht erforderlich, wenn alle Threads vollständig unabhängig voneinander ausgeführt werden, auch wenn sie über mehrere Threads verfügen. Ein solcher Zustand wird gesagt, dass der Thread nicht ** stört **. --Wenn sich der Status der SharedResource-Rolle ändern kann. Sie müssen das Single Thread Execution-Muster nicht verwenden, wenn keine Möglichkeit besteht, dass sich der Status ändert. Das unveränderliche Muster (später beschrieben) entspricht diesem.
Wenn Sie sicher bleiben müssen. Viele Java-Sammlungsklassen sind nicht threadsicher. Dies dient dazu, einen Hochgeschwindigkeitsbetrieb zu ermöglichen, wenn die Sicherheit nicht gewährleistet werden muss. Klassen, die nicht threadsicher sind, werden in der API-Referenz angegeben.

Java bietet übrigens eine Methode, um die Auflistungsklasse threadsicher zu machen.

--synchronizedCollection-Methode --synchronizedList-Methode --synchronizedMap-Methode --synchronizedSet-Methode --synchronizedSortedMap-Methode --synchronizedSoretedSet-Methode

Überlebensfähigkeit und Dead Lock

** Dies ist sehr wichtig, schreiben Sie es daher sorgfältig. ** ** **

Ein Deadlock bei der Ausführung mit einem Thread tritt auf, wenn alle folgenden Bedingungen erfüllt sind:

Es gibt mehrere SharedResource-Rollen.
Der Thread ruft die Sperre einer anderen SharedResource-Rolle ab, während die Sperre einer SharedResource-Rolle beibehalten wird.
Die Reihenfolge des Sperren der SharedResource-Rolle ist nicht festgelegt.

Angenommen, A und B essen den Reis vor sich. Sie brauchen sowohl einen Löffel als auch eine Gabel, um zu essen. Angenommen, A nimmt einen Löffel und B nimmt eine Gabel. Zu diesem Zeitpunkt wartet A darauf, dass B die Gabel setzt, und B wartet darauf, dass A den Löffel setzt. Dead Lock tritt auf. In diesem Beispiel

Es gibt mehrere SharedResource-Rollen, Löffel und Gabel.
Wenn Sie versuchen, die Gabel des Gegners zu halten, während Sie den Löffel halten, versuchen Sie, ein weiteres Schloss zu bekommen, während Sie das Schloss halten.
Dieses Mal kann die Reihenfolge von Löffel → Gabel oder Gabel → Löffel verwendet werden, sodass die Reihenfolge der Verriegelung nicht festgelegt wird.

Daher ist eine Deadlock aufgetreten. Versuchen Sie in diesem Beispiel, entweder Bedingung 1 oder 2 oder 3 zu brechen.

Versuchen Sie, 1 zu brechen. Sie brauchen nur einen Löffel zum Essen. Damit tritt keine Deadlock auf. Versuchen Sie, 2 zu brechen. Hör auf, die Gabel zu holen, während du den Löffel hältst. Wenn Sie mit einem Löffel essen können, essen Sie mit einem Löffel. Wenn Sie mit dem Essen fertig sind, setzen Sie den Löffel einmal ein und holen Sie sich die nächste Gabel. Dies führt nicht zu einem Dead Lock. Versuche 3 zu brechen. Stellen Sie sicher, dass Sie den Löffel und die Gabel in dieser Reihenfolge nehmen müssen. Wenn A dann den Löffel aufnimmt, kann A die Gabel aufheben, weil B warten muss, bis der Löffel platziert ist (weil B die Gabel niemals aufnimmt). Es tritt keine Deadlock auf.

Wiederverwendbarkeits- und Vererbungsanomalien

Selbst wenn die SharedResource-Rolle genau zur Gewährleistung der Sicherheit erstellt wird, besteht das Risiko, dass die Sicherheit durch Unterklassen zerstört wird. Vererbung kann bei der Multithread-Programmierung zu problematischen Problemen führen. Dies wird als ** Vererbungsfehler ** bezeichnet.

Kritische Abschnittsgröße und Leistung

Im Allgemeinen verschlechtert das Single Threaded Execution-Muster die Leistung.

Grund 1: Es dauert einige Zeit, um das Schloss zu erhalten
Grund 2: Weil Sie wegen einer Thread-Kollision warten müssen

Denken Sie an synchronisiert

Ist der folgende Code beispielsweise der gleiche wie der Code, der synchronisiert verwendet wird?

void method() {
    lock(); //Angenommen, es gibt eine solche Methode
    ...
    unlock(); //Angenommen, es gibt eine solche Methode
}

Die Antwort ist nicht dieselbe. Dies liegt daran, dass die Sperre nicht freigegeben wird, wenn eine Rückgabe- oder Ausnahmebehandlung zwischen lock () und entsperren () ausgeführt wird. Auf der anderen Seite lösen die synchronisierte Methode und der synchronisierte Block die Sperre beim Beenden von {}. Unabhängig davon, ob Sie eine Ausnahme in der Mitte zurückgeben oder auslösen, wird die Sperre mit Sicherheit aufgehoben. Wenn Sie zwei Methoden wie lock () und entsperren () haben und unabhängig (was passiert) Unlock () aufrufen möchten, verwenden Sie ** finally **.

void method
    lock();
    try {
        ...
    } finally {
        unlock(); //Endlich entsperren
    }
}

Wie man es endlich so benutzt, ist eine der Möglichkeiten, ** Vorher / Nachher-Muster ** zu realisieren.

Beachten Sie Folgendes für synchronisierte Methoden und synchronisierte Blöcke.

――Was schützen Sie?

Bewahren Sie es an anderen Orten auf? ――Welches Gerät sollten Sie schützen?
Welche Instanz möchten Sie sperren?

Atombetrieb

Substitutionen und Referenzen für primitiven Typ und Referenztyp sind ** atomar **. Das heißt, wenn ein Thread eine Zuweisung von n = 123 und ein anderer Thread eine Zuweisung von n = 456 vornimmt, ist n immer 123 oder 456. Gemäß den Java-Sprachspezifikationen sind lange und doppelte Zuweisungen und Referenzen jedoch nicht atomar. In der Realität werden viele Java-Sprachverarbeitungssysteme sowohl lange als auch doppelte atomare Operationen implementieren. Mit dem Schlüsselwort ** volatile ** wird die Operation in diesem Feld atomar.

Semapho zählen

Single Threaded Execution ist ein Muster, bei dem nur "nur ein Thread" einen bestimmten Bereich ausführt. ** Semapho zählen * ermöglicht die Ausführung eines bestimmten Bereichs bis zu "bis zu N Threads". Das Paket ** java.util.concurrent ** enthält die Klasse ** Semaphore ** zum Zählen von Semaphos. Geben Sie die Anzahl der Ressourcen (Genehmigungen) im Konstruktor von Semaphore an. Weisen Sie Ressourcen mit der ** Erwerb ** -Methode von Semaphore zu und geben Sie die Freigabe mit der ** Freigabemethode ** frei. Acquire und Release müssen immer paarweise aufgerufen werden. Daher wird empfohlen, das oben erwähnte Vorher / Nachher-Muster endgültig zu verwenden.

Beziehung Zusammenfassung der in Java-Sprache erlernten Entwurfsmuster (Multi-Thread-Edition) "(Teil 1) Zusammenfassung der in Java-Sprache erlernten Entwurfsmuster (Multithreaded Edition) "(Teil 2)

Zusammenfassung von "In Java gelernte Entwurfsmuster (Multithread Edition)" (Teil 3)