ILock Schnittstelle

Definition

[Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")]
public interface ILock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")>]
type ILock = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Abgeleitet

Java.Util.Concurrent.Locks.ReentrantLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantReadLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantWriteLock

Attribute

RegisterAttribute

Implementiert

IJavaObject IJavaPeerable IDisposable

Hinweise

Lock Implementierungen bieten umfangreichere Sperrvorgänge, als mithilfe von synchronized Methoden und Anweisungen abgerufen werden können. Sie ermöglichen eine flexiblere Strukturierung, können unterschiedliche Eigenschaften aufweisen und mehrere zugeordnete Condition Objekte unterstützen.

Eine Sperre ist ein Tool zum Steuern des Zugriffs auf eine freigegebene Ressource durch mehrere Threads. Häufig bietet eine Sperre exklusiven Zugriff auf eine freigegebene Ressource: Nur jeweils ein Thread kann die Sperre abrufen und der gesamte Zugriff auf die freigegebene Ressource erfordert, dass die Sperre zuerst abgerufen wird. Einige Sperren ermöglichen jedoch möglicherweise gleichzeitigen Zugriff auf eine freigegebene Ressource, z. B. die Lesesperre einer ReadWriteLock.

Die Verwendung von synchronized Methoden oder Anweisungen bietet Zugriff auf die implizite Monitorsperre, die mit jedem Objekt verknüpft ist, erzwingt jedoch den Gesamten Lock-Erwerb und die Freigabe auf eine blockstrukturierte Weise: Wenn mehrere Sperren abgerufen werden, müssen sie in der entgegengesetzten Reihenfolge freigegeben werden, und alle Sperren müssen im selben lexikalischen Bereich freigegeben werden, in dem sie erworben wurden.

Während der Bereichsmechanismus für synchronized Methoden und Anweisungen das Programmieren mit Monitorsperren viel einfacher macht und hilft, viele häufige Programmierfehler mit Sperren zu vermeiden, gibt es Situationen, in denen Sie mit Sperren auf flexiblere Weise arbeiten müssen. Zum Beispiel erfordern einige Algorithmen zum Durchlaufen gleichzeitig aufgerufener Datenstrukturen die Verwendung von " Handübergabe" oder " Verkettungssperre": Sie erwerben die Sperre von Knoten A, dann Knoten B, freigeben und C erwerben, dann B freigeben und D usw. erwerben. Implementierungen der Lock Schnittstelle ermöglichen die Verwendung solcher Techniken, indem eine Sperre in verschiedenen Bereichen erworben und freigegeben werden kann und mehrere Sperren in beliebiger Reihenfolge erworben und freigegeben werden können.

Mit dieser erhöhten Flexibilität kommt zusätzliche Verantwortung. Wenn blockstrukturierte Sperren nicht vorhanden sind, wird die automatische Freigabe von Sperren entfernt, die mit synchronized Methoden und Anweisungen auftreten. In den meisten Fällen sollte der folgende Idiom verwendet werden:

{@code
            Lock l = ...;
            l.lock();
            try {
              // access the resource protected by this lock
            } finally {
              l.unlock();
            }}

Wenn das Sperren und Entsperren in verschiedenen Bereichen auftreten, müssen Sie sicherstellen, dass der gesamte Code, der ausgeführt wird, während die Sperre gehalten wird, durch try-finally oder try-catch geschützt ist, um sicherzustellen, dass die Sperre bei Bedarf freigegeben wird.

Lock Implementierungen bieten zusätzliche Funktionen über die Verwendung von synchronized Methoden und Anweisungen, indem ein nicht blockierender Versuch zum Abrufen einer Sperre (#tryLock()) bereitgestellt wird, ein Versuch, die Sperre abzurufen, die unterbrochen werden kann (#lockInterruptiblyund ein Versuch, die Sperre abzurufen, die timeout (#tryLock(long, TimeUnit)) kann.

Eine Lock Klasse kann auch Verhalten und Semantik bereitstellen, die sich von der impliziten Monitorsperre unterscheidet, z. B. garantierte Sortierung, nicht wiederholte Verwendung oder Deadlockerkennung. Wenn eine Implementierung eine solche spezialisierte Semantik bereitstellt, muss die Implementierung diese Semantik dokumentieren.

Beachten Sie, dass Lock Instanzen nur normale Objekte sind und selbst als Ziel in einer synchronized Anweisung verwendet werden können. Das Abrufen der Monitorsperre einer Lock Instanz hat keine angegebene Beziehung zum Aufrufen einer der #lock Methoden dieser Instanz. Es wird empfohlen, Verwirrung zu vermeiden, dass Sie niemals Instanzen auf diese Weise verwenden Lock , außer innerhalb ihrer eigenen Implementierung.

Sofern nicht angegeben, führt die Übergabe eines null Werts für einen Beliebigen Parameter zu einem NullPointerException Auslösen.

<h2>Speichersynchronisierung</h2>

Alle Lock Implementierungen em<must>/em< erzwingen die gleiche Speichersynchronisierungsemantik wie in der integrierten Monitorsperre angegeben, wie in Kapitel 17 des >Zitats<> "Die Java Sprachspezifikation</zitat: ><ul><li>A erfolgreiche lock Operation hat dieselben Speichersynchronisierungseffekte wie eine erfolgreiche <Em Lock></em-Aktion.> <Li>Ein erfolgreicher unlock Vorgang hat dieselben Speichersynchronisierungseffekte wie eine erfolgreiche <Em-Entsperrungs><-/Em-Aktion>. </ul>

Bei nicht erfolgreichen Sperr- und Entsperrungsvorgängen und erneuten Sperr-/Entsperrvorgängen sind keine Speichersynchronisierungseffekte erforderlich.

<Überlegungen> zur h2-Implementierung</h2>

Die drei Formen der Sperrerfassung (unterbrechungsfähig, nicht unterbrechbar und zeitgesteuerte) können sich in ihren Leistungseigenschaften, Bestellgarantien oder anderen Implementierungsqualitäten unterscheiden. Darüber hinaus ist die Möglichkeit, den <laufenden>/<em-Erwerb> einer Sperre zu unterbrechen, möglicherweise nicht in einer bestimmten Lock Klasse verfügbar. Daher ist eine Implementierung nicht erforderlich, um genau die gleichen Garantien oder Semantik für alle drei Formen des Lock-Erwerbs zu definieren, noch ist es erforderlich, Unterbrechungen einer laufenden Lock-Akquisition zu unterstützen. Eine Implementierung ist erforderlich, um die Semantik und Garantien, die von den einzelnen Sperrmethoden bereitgestellt werden, klar zu dokumentieren. Sie muss auch die Unterbrechungsemantik befolgen, wie in dieser Schnittstelle definiert, soweit die Unterbrechung der Sperrerfassung unterstützt wird: entweder vollständig oder nur bei der Methodeneingabe.

Da Unterbrechungen in der Regel absagen und Überprüfungen auf Unterbrechungen häufig selten sind, kann eine Implementierung das Reagieren auf einen Interrupt über die normale Methodenrückgabe bevorzugen. Dies gilt auch dann, wenn gezeigt werden kann, dass der Interrupt nach einer anderen Aktion den Thread aufgehoben hat. Eine Implementierung sollte dieses Verhalten dokumentieren.

Hinzugefügt in 1.5.

Java Dokumentation für java.util.concurrent.locks.Lock.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.