Schnittstellenzustand
- 巴扎黑Original
- 2017-06-26 11:26:571182Durchsuche
java.util.concurrent.locks-Schnittstellenbedingung
Alle bekannten Implementierungsklassen:
AbstractQueuedLongSynchronizer , AbstractQueuedSynchronizer.ConditionObject
public interface Condition
<br>
Condition Überwacht Object Methoden (wait, notify und notifyAll) In verschiedene Objekte zerlegt, kann verwendet werden , indem diese -Objekte mit einer beliebigen Lock-Implementierung kombiniert werden, wobei für jedes Objekt mehrere Waitsets (Warten) bereitgestellt werden. Unter anderem ersetzt Lock die Verwendung von synchronized-Methoden und -Anweisungen und Condition ersetzt die Verwendung von Objektmonitormethoden . Eine
-Bedingung (auch Bedingungswarteschlange oder Bedingungsvariable genannt) gibt einem Thread eine Bedeutung, sodass in einem bestimmten Zustand eine Bedingung nun wahr sein kann Ein anderer Thread Der Thread wird angehalten (d. h. zum „Warten“ gebracht), bis er benachrichtigt wird. Da der Zugriff auf diese gemeinsam genutzten Statusinformationen in einem anderen Thread erfolgt, muss er geschützt werden, sodass der Bedingung eine Art Sperre zugeordnet wird. Die Haupteigenschaften einer Wartebedingung sind: atomar gibt die zugehörige Sperre frei und unterbricht den aktuellen Thread, genau wie Object.wait dies tut.
Condition Die Instanz ist grundsätzlich an eine Sperre gebunden. Um eine -Instanz für eine bestimmte LockCondition-Instanz zu erhalten, verwenden Sie deren Methode newCondition().
Angenommen, es gibt einen gebundenen Puffer, der die Methoden put und take unterstützt. Wenn Sie versuchen, eine take-Operation für einen leeren Puffer auszuführen, wird der Thread blockiert, bis ein Element verfügbar wird; wenn Sie versuchen, eine put-Operation für einen vollen Puffer auszuführen, wird der Thread blockiert, bis Platz verfügbar wird , wäre der Thread blockiert worden. Wir möchten put-Threads und take-Threads in separaten Wartesätzen aufbewahren, damit wir von einer optimalen Planung profitieren und jeweils nur einen Thread benachrichtigen können, wenn ein Element oder Platz im Puffer verfügbar wird. Dies kann mithilfe von zwei Condition-Instanzen erfolgen.
class BoundedBuffer { final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
final Object[] items = new Object[100];
int putptr, takeptr, count;
public void put(Object x) throws InterruptedException { lock.lock();
try { while (count == items.length)
notFull.await(); items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count; notEmpty.signal(); } finally {
lock.unlock();
}
}
public Object take() throws InterruptedException { lock.lock();
try { while (count == 0)
notEmpty.await(); Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count; notFull.signal(); return x; } finally {
lock.unlock();
}
}
}
(Die ArrayBlockingQueue-Klasse stellt diese Funktionalität bereit, daher gibt es keinen Grund, diese Beispielklasse zu implementieren.)
Condition-Implementierungen können andere Überwachungsmethoden als die Verhalten und Semantik, wie z. B. garantierte Reihenfolge von Benachrichtigungen oder die Notwendigkeit, beim Ausführen von Benachrichtigungen eine Sperre aufrechtzuerhalten. Wenn eine Implementierung eine solche spezielle Semantik bereitstellt, MUSS die Implementierung diese Semantik dokumentieren. Object
-Instanzen nur einfache Objekte sind, die selbst als Ziele in Condition-Anweisungen verwendet werden können und ihre eigenen synchronized- und wait-Überwachungsmethoden aufrufen können. Das Erhalten der Monitorsperre einer notification-Instanz oder die Verwendung ihrer Monitormethoden hat nichts speziell mit dem Erwerb des mit dieser Condition verknüpften Condition oder der Verwendung ihrer Lock- und waiting-Methoden zu tun. Um Verwirrung zu vermeiden, wird empfohlen, signalling-Instanzen niemals auf diese Weise zu verwenden, außer innerhalb ihrer eigenen Implementierung. Condition
-Werts für ein beliebiges Argument dazu, dass null ausgelöst wird. NullPointerException
darf ein „Conditionfalsches Wake“ auftreten, normalerweise als Zugeständnis an die zugrunde liegende Plattformsemantik. Für die meisten Anwendungen wird dies kaum praktische Auswirkungen haben, da immer in einer Schleife erwartet werden sollte und die erwartete Zustandsanweisung testen soll. Es steht einer Implementierung frei, mögliche unerwünschte Wakeups zu entfernen. Anwendungsprogrammierern wird jedoch empfohlen, immer davon auszugehen, dass diese unerwünschten Wakeups auftreten können, und daher immer in einer Schleife zu warten. Condition
ist die Möglichkeit, die tatsächliche Unterbrechung eines Threads zu unterbrechen, nicht immer auf allen Plattformen möglich.
Daher ist es nicht erforderlich, dass eine Implementierung genau die gleichen Garantien oder Semantiken für alle drei Formen des Wartens definiert, noch ist es erforderlich, das tatsächliche Anhalten von Interrupt-Threads zu unterstützen. Implementierungen müssen die von jeder Wartemethode bereitgestellte Semantik und Garantien klar dokumentieren. Wenn eine Implementierung das Anhalten von Interrupt-Threads nicht unterstützt, muss sie der in dieser Schnittstelle definierten Interrupt-Semantik entsprechen.Da Interrupts normalerweise einen Abbruch bedeuten und Interrupt-Prüfungen normalerweise selten durchgeführt werden, können Implementierungen auf Interrupts reagieren, bevor normale Methoden zurückkehren. Dies gilt auch dann, wenn ein Interrupt, der nach einem anderen Vorgang auftritt, die Thread-Sperre aufheben könnte. Implementierungen sollten dieses Verhalten dokumentieren.
Ab:
1,5
<br>
| |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
void |
await () <br> Bewirkt, dass sich der aktuelle Thread im Wartezustand befindet, bis er ein Signal empfängt oder unterbrochen wird . |
||||||||||||||||
boolean |
await<table style="width: 100%" border="1"><tbody><tr class="TableHeadingColor"><th align="left"><span style="font-size: small"><strong>方法详细信息</strong></span></th></tr></tbody></table>(lange Zeit, TimeUnit-Einheit) Bewirkt, dass sich der aktuelle Thread in einem Wartezustand befindet, bis er ein Signal empfängt, unterbrochen wird oder die angegebene Wartezeit erreicht.
|
||||||||||||||||
long |
awaitNanos(long nanosTimeout) Bewirkt, dass der aktuelle Thread im Wartezustand bleibt, bis er ein Signal empfängt, unterbrochen wird oder die angegebene Wartezeit erreicht.
|
||||||||||||||||
void |
awaitUninterruptously() span> Bewirkt, dass der aktuelle Thread wartet, bis er das Signal empfängt. |
||||||||||||||||
boolean |
awaitUntil(Datumsfrist) Bewirkt, dass der aktuelle Thread wartet, bis er ein Signal empfängt, unterbrochen wird oder die angegebene Frist erreicht.
|
||||||||||||||||
void |
signal() span> Wecken Sie einen wartenden Thread auf. |
||||||||||||||||
void |
signalAll() span> Weckt alle wartenden Threads auf. |
||||||||||||||||
| Methodendetails |
|---|
<br>
await
void await() throws InterruptedException
-
造成当前线程在接到信号或被中断之前一直处于等待状态。
与此
Condition相关的锁以原子方式释放，并且出于线程调度的目的，将禁用当前线程，且在发生以下四种情况之一 以前，当前线程将一直处于休眠状态：其他某个线程调用此
Condition的signal()方法，并且碰巧将当前线程选为被唤醒的线程；或者其他某个线程调用此
Condition的signalAll()方法；或者其他某个线程中断当前线程，且支持中断线程的挂起；或者
发生“虚假唤醒”
在所有情况下，在此方法可以返回当前线程之前，都必须重新获取与此条件有关的锁。在线程返回时，可以保证 它保持此锁。
如果当前线程：
在进入此方法时已经设置了该线程的中断状态；或者
在支持等待和中断线程挂起时，线程被中断，
则抛出
InterruptedException，并清除当前线程的中断状态。在第一种情况下，没有指定是否在释放锁之前发生中断测试。实现注意事项
假定调用此方法时，当前线程保持了与此
Condition有关联的锁。这取决于确定是否为这种情况以及不是时，如何对此作出响应的实现。通常，将抛出一个异常（比如IllegalMonitorStateException）并且该实现必须对此进行记录。与响应某个信号而返回的普通方法相比，实现可能更喜欢响应某个中断。在这种情况下，实现必须确保信号被重定向到另一个等待线程（如果有的话）。
抛出：
InterruptedException- 如果当前线程被中断（并且支持中断线程挂起）
<br>
awaitUninterruptibly
void awaitUninterruptibly()
-
造成当前线程在接到信号之前一直处于等待状态。
与此条件相关的锁以原子方式释放，并且出于线程调度的目的，将禁用当前线程，且在发生以下三种情况之一 以前，当前线程将一直处于休眠状态：
其他某个线程调用此
Condition的signal()方法，并且碰巧将当前线程选为被唤醒的线程；或者其他某个线程调用此
Condition的signalAll()方法；或者发生“虚假唤醒”
在所有情况下，在此方法可以返回当前线程之前，都必须重新获取与此条件有关的锁。在线程返回时，可以保证 它保持此锁。
如果在进入此方法时设置了当前线程的中断状态，或者在等待时，线程被中断，那么在接到信号之前，它将继续等待。当最终从此方法返回时，仍然将设置其中断状态。
实现注意事项
假定调用此方法时，当前线程保持了与此
Condition有关联的锁。这取决于确定是否为这种情况以及不是时，如何对此作出响应的实现。通常，将抛出一个异常（比如IllegalMonitorStateException）并且该实现必须对此进行记录。
<br>
awaitNanos
long awaitNanos(long nanosTimeout) throws InterruptedException
-
造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
与此条件相关的锁以原子方式释放，并且出于线程调度的目的，将禁用当前线程，且在发生以下五种情况之一 以前，当前线程将一直处于休眠状态：
其他某个线程调用此
Condition的signal()方法，并且碰巧将当前线程选为被唤醒的线程；或者其他某个线程调用此
Condition的signalAll()方法；或者其他某个线程中断当前线程，且支持中断线程的挂起；或者
已超过指定的等待时间；或者
发生“虚假唤醒”。
在所有情况下，在此方法可以返回当前线程之前，都必须重新获取与此条件有关的锁。在线程返回时，可以保证 它保持此锁。
如果当前线程：
在进入此方法时已经设置了该线程的中断状态；或者
在支持等待和中断线程挂起时，线程被中断，
则抛出
InterruptedException，并且清除当前线程的已中断状态。在第一种情况下，没有指定是否在释放锁之前发生中断测试。在返回时，该方法返回了所剩毫微秒数的一个估计值，以等待所提供的
nanosTimeout值的时间，如果超时，则返回一个小于等于 0 的值。可以用此值来确定在等待返回但某一等待条件仍不具备的情况下，是否要再次等待，以及再次等待的时间。此方法的典型用法采用以下形式：synchronized boolean aMethod(long timeout, TimeUnit unit) { long nanosTimeout = unit.toNanos(timeout); while (!conditionBeingWaitedFor) { if (nanosTimeout > 0) nanosTimeout = theCondition.awaitNanos(nanosTimeout); else return false; } // ... }设计注意事项：此方法需要一个 nanosecond 参数，以避免在报告剩余时间时出现截断错误。在发生重新等待时，这种精度损失使得程序员难以确保总的等待时间不少于指定等待时间。
实现注意事项
假定调用此方法时，当前线程保持了与此
Condition有关联的锁。这取决于确定是否为这种情况以及不是时，如何对此作出响应的实现。通常会抛出一个异常（比如IllegalMonitorStateException）并且该实现必须对此进行记录。与响应某个信号而返回的普通方法相比，或者与指示所使用的指定等待时间相比，实现可能更喜欢响应某个中断。在任意一种情况下，实现必须确保信号被重定向到另一个等待线程（如果有的话）。
参数：
nanosTimeout- 等待的最长时间，以毫微秒为单位返回：
nanosTimeout值减去花费在等待此方法的返回结果的时间的估算。正值可以用作对此方法进行后续调用的参数，来完成等待所需时间结束。小于等于零的值表示没有剩余时间。抛出：
InterruptedException- 如果当前线程被中断（并且支持中断线程挂起）
<br>
await
boolean await(long time, TimeUnit unit) throws InterruptedException
-
造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。此方法在行为上等效于：
awaitNanos(unit.toNanos(time)) > 0
参数：
time- 最长等待时间unit-time参数的时间单位返回：
如果在从此方法返回前检测到等待时间超时，则返回
false，否则返回true抛出：
InterruptedException- 如果当前线程被中断（并且支持中断线程挂起）
<br>
awaitUntil
boolean awaitUntil(Date deadline) throws InterruptedException
-
造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。
与此条件相关的锁以原子方式释放，并且出于线程调度的目的，将禁用当前线程，且在发生以下五种情况之一 以前，当前线程将一直处于休眠状态：
其他某个线程调用此
Condition的signal()方法，并且碰巧将当前线程选为被唤醒的线程；或者其他某个线程调用此
Condition的signalAll()方法；或者其他某个线程中断当前线程，且支持中断线程的挂起；或者
指定的最后期限到了；或者
发生“虚假唤醒”。
在所有情况下，在此方法可以返回当前线程之前，都必须重新获取与此条件有关的锁。在线程返回时，可以保证 它保持此锁。
如果当前线程：
在进入此方法时已经设置了该线程的中断状态；或者
在支持等待和中断线程挂起时，线程被中断，
则抛出
InterruptedException，并且清除当前线程的已中断状态。在第一种情况下，没有指定是否在释放锁之前发生中断测试。返回值指示是否到达最后期限，使用方式如下：
synchronized boolean aMethod(Date deadline) { boolean stillWaiting = true; while (!conditionBeingWaitedFor) { if (stillWaiting) stillWaiting = theCondition.awaitUntil(deadline); else return false; } // ... }实现注意事项
假定调用此方法时，当前线程保持了与此
Condition有关联的锁。这取决于确定是否为这种情况以及不是时，如何对此作出响应的实现。通常，将抛出一个异常（比如IllegalMonitorStateException）并且该实现必须对此进行记录。与响应某个信号而返回的普通方法相比，或者与指示是否到达指定最终期限相比，实现可能更喜欢响应某个中断。在任意一种情况下，实现必须确保信号被重定向到另一个等待线程（如果有的话）。
参数：
deadline- 一直处于等待状态的绝对时间返回：
如果在返回时已经到达最后期限，则返回
false，否则返回true抛出：
InterruptedException- 如果当前线程被中断（并且支持中断线程挂起）
<br>
signal
void signal()
-
唤醒一个等待线程。
如果所有的线程都在等待此条件，则选择其中的一个唤醒。在从
await返回之前，该线程必须重新获取锁。
<br>
signalAll
void signalAll()
-
唤醒所有等待线程。
如果所有的线程都在等待此条件，则唤醒所有线程。在从
await返回之前，每个线程都必须重新获取锁。
Das obige ist der detaillierte Inhalt vonSchnittstellenzustand. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!