Класс AbstractQueuedSynchronizer

public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements Serializable

Предоставляет основу для реализации блокирующих замков и связанных синхронизаторов (семафоров, событий и т. д.), которые полагаются на очереди ожидания «первый пришёл — первый обслужен» (FIFO). Этот класс разработан в качестве полезной основы для большинства типов синхронизаторов, которые полагаются на единственное атомарное int значение для представления состояния. Подклассы должны определить защищённые методы, которые изменяют это состояние и определяют, что это состояние означает в терминах приобретения или освобождения этого объекта. Учитывая это, другие методы в этом классе выполняют все механизмы очереди и блокировки. Подклассы могут поддерживать другие поля состояния, но только атомарно обновлённое int значение, манипулируемое методами getState(), setState(int) и compareAndSetState(int, int), отслеживается относительно синхронизации.

Подклассы должны быть определены как непубличные внутренние вспомогательные классы, которые используются для реализации свойств синхронизации их окружающего класса. Класс AbstractQueuedSynchronizer не реализует ни один интерфейс синхронизации. Вместо этого он определяет методы, такие как acquireInterruptibly(int), которые могут вызываться соответствующим образом конкретными замками и связанными синхронизаторами для реализации их публичных методов.

Этот класс поддерживает или то, или другое, или и то, и другое — режим по умолчанию исключительный и режим разделяемый. При приобретении в режиме исключения попытки приобретения другими потоками не могут иметь успеха. Приобретения в режиме разделяемого доступа несколькими потоками могут (но не обязаны) иметь успех. Этот класс не «понимает» этих различий, за исключением механического смысла, что когда приобретение в режиме разделяемого доступа имеет успех, следующий ожидающий поток (если он существует) также должен определить, может ли он приобрести также. Потоки, ожидающие в разных режимах, используют одну и ту же очередь FIFO. Как правило, подклассы реализации поддерживают только один из этих режимов, но оба могут вступать в игру, например, в ReadWriteLock. Подклассы, которые поддерживают только исключительные или только разделяемые режимы, не обязаны определять методы, поддерживающие неиспользуемый режим.

Этот класс определяет вложенный класс AbstractQueuedSynchronizer.ConditionObject, который может использоваться в качестве реализации Condition подклассами, поддерживающими режим исключения, для которых метод isHeldExclusively() сообщает, захвачена ли синхронизация исключительно текущим потоком, метод release(int), вызванный с текущим значением getState(), полностью освобождает этот объект, и acquire(java.util.concurrent.locks.AbstractQueuedSynchronizer.Node, int, boolean, boolean, boolean, long), учитывая это сохранённое значение состояния, в конечном итоге восстанавливает этот объект в его предыдущее состояние приобретения. Ни один AbstractQueuedSynchronizer метод иначе не создаёт такую условную переменную, поэтому если это ограничение не может быть выполнено, не используйте её. Поведение AbstractQueuedSynchronizer.ConditionObject зависит, конечно, от семантики реализации его синхронизатора.

Этот класс предоставляет методы инспекции, инструментирования и мониторинга внутренней очереди, а также аналогичные методы для объектов условных переменных. Эти методы могут по желанию экспортироваться в классы, использующие AbstractQueuedSynchronizer для своих механизмов синхронизации.

Сериализация этого класса сохраняет только базовый атомарный целочисленный тип, поддерживающий состояние, поэтому у десериализованных объектов пустые очереди потоков. Типичные подклассы, требующие сериализуемости, определят метод readObject , который восстанавливает это в известное начальное состояние при десериализации.

Использование

Для использования этого класса в качестве основы синхронизатора переопределите следующие методы, применимые, проверяя и/или изменяя состояние синхронизации с помощью getState(), setState(int) и/или compareAndSetState(int, int):

• tryAcquire(int)
• tryRelease(int)
• tryAcquireShared(int)
• tryReleaseShared(int)
• isHeldExclusively()

Каждый из этих методов по умолчанию выбрасывает UnsupportedOperationException. Реализации этих методов должны быть внутренне потокобезопасными и, как правило, короткими и не должны блокировать. Определение этих методов является единственным поддерживаемым способом использования этого класса. Все остальные методы объявлены final , потому что они не могут быть независимо изменены.

Вы также можете найти полезными унаследованные методы из AbstractOwnableSynchronizer для отслеживания потока, владеющего исключительным синхронизатором. Рекомендуется их использовать — это позволяет инструментам мониторинга и диагностики помочь пользователям в определении того, какие потоки владеют замками.

Несмотря на то, что этот класс основан на внутренней очереди FIFO, он не автоматически навязывает политики приобретения FIFO. Ядро исключительной синхронизации имеет вид:

 Acquire:
     while (!tryAcquire(arg)) {
        enqueue thread if it is not already queued;
        possibly block current thread;
     }

 Release:
     if (tryRelease(arg))
        unblock the first queued thread;
 

(Режим разделяемого доступа аналогичен, но может включать каскадные сигналы.)

Поскольку проверки в приобретении вызываются до помещения в очередь, новый поток, приобретающий, может прорваться вперёд других заблокированных и помещённых в очередь потоков. Однако, если необходимо, вы можете определить tryAcquire и/или tryAcquireShared для отключения прорывания, вызвав один или несколько методов проверки внутри, тем самым обеспечив честную политику приобретения FIFO. В частности, большинство честных синхронизаторов могут определить tryAcquire для возврата false , если hasQueuedPredecessors() (метод, специально предназначенный для использования честными синхронизаторами) возвращает true. Возможны и другие варианты.

Производительность и масштабируемость, как правило, выше для стратегии прорывания по умолчанию (также известной как жадная, отказная и избегающая конвоя) стратегия. Хотя это не гарантирует справедливости или отсутствия голодания, более ранние потоки в очереди получают возможность снова конкурировать до того, как более поздние потоки в очереди, и каждая новая попытка получить доступ имеет беспристрастный шанс преуспеть в конкуренции с вновь входящими потоками. Кроме того, хотя приобретения не «вращаются» в обычном смысле, они могут выполнить несколько вызовов tryAcquire, перемежающихся с другими вычислениями, прежде чем заблокироваться. Это даёт большинство преимуществ вращений, когда исключительная синхронизация удерживается только в течение короткого времени, без большинства недостатков, когда этого нет. При желании вы можете дополнить это, предварив вызовы методов приобретения «проверками быстрого пути», возможно, предварительно проверив hasContended() и/или hasQueuedThreads(), чтобы сделать это только в том случае, если синхронизатор, скорее всего, не будет подвергаться конкуренции.

Этот класс предоставляет эффективную и масштабируемую основу для синхронизации, частично специализируясь на использовании синхронизаторами, которые могут полагаться на int состояния, параметры приобретения и освобождения и внутренней очереди ожидания FIFO. Когда этого недостаточно, вы можете создавать синхронизаторы с более низкого уровня с использованием atomic классов, собственных пользовательских Queue классов и LockSupport поддержки блокировки.

Примеры использования

Вот класс нерекурсивного взаимного исключения, который использует значение ноль для представления разблокированного состояния и один для представления заблокированного состояния. Хотя нерекурсивному замку строго не требуется запись текущего владельца потока, этот класс делает это для удобства мониторинга использования. Он также поддерживает условные переменные и предоставляет некоторые методы инструментирования:

 
 class Mutex implements Lock, java.io.Serializable {

   // Our internal helper class
   private static class Sync extends AbstractQueuedSynchronizer {
     // Acquires the lock if state is zero
     public boolean tryAcquire(int acquires) {
       assert acquires == 1; // Otherwise unused
       if (compareAndSetState(0, 1)) {
         setExclusiveOwnerThread(Thread.currentThread());
         return true;
       }
       return false;
     }

     // Releases the lock by setting state to zero
     protected boolean tryRelease(int releases) {
       assert releases == 1; // Otherwise unused
       if (!isHeldExclusively())
         throw new IllegalMonitorStateException();
       setExclusiveOwnerThread(null);
       setState(0);
       return true;
     }

     // Reports whether in locked state
     public boolean isLocked() {
       return getState() != 0;
     }

     public boolean isHeldExclusively() {
       // a data race, but safe due to out-of-thin-air guarantees
       return getExclusiveOwnerThread() == Thread.currentThread();
     }

     // Provides a Condition
     public Condition newCondition() {
       return new ConditionObject();
     }

     // Deserializes properly
     private void readObject(ObjectInputStream s)
         throws IOException, ClassNotFoundException {
       s.defaultReadObject();
       setState(0); // reset to unlocked state
     }
   }

   // The sync object does all the hard work. We just forward to it.
   private final Sync sync = new Sync();

   public void lock()              { sync.acquire(1); }
   public boolean tryLock()        { return sync.tryAcquire(1); }
   public void unlock()            { sync.release(1); }
   public Condition newCondition() { return sync.newCondition(); }
   public boolean isLocked()       { return sync.isLocked(); }
   public boolean isHeldByCurrentThread() {
     return sync.isHeldExclusively();
   }
   public boolean hasQueuedThreads() {
     return sync.hasQueuedThreads();
   }
   public void lockInterruptibly() throws InterruptedException {
     sync.acquireInterruptibly(1);
   }
   public boolean tryLock(long timeout, TimeUnit unit)
       throws InterruptedException {
     return sync.tryAcquireNanos(1, unit.toNanos(timeout));
   }
 }

Вот класс счётчика, который похож на CountDownLatch, за исключением того, что он требует только одного signal для срабатывания. Поскольку счётчик не является исключительным, он использует shared методы приобретения и освобождения.

 
 class BooleanLatch {

   private static class Sync extends AbstractQueuedSynchronizer {
     boolean isSignalled() { return getState() != 0; }

     protected int tryAcquireShared(int ignore) {
       return isSignalled() ? 1 : -1;
     }

     protected boolean tryReleaseShared(int ignore) {
       setState(1);
       return true;
     }
   }

   private final Sync sync = new Sync();
   public boolean isSignalled() { return sync.isSignalled(); }
   public void signal()         { sync.releaseShared(1); }
   public void await() throws InterruptedException {
     sync.acquireSharedInterruptibly(1);
   }
 }