Интерфейс Condition

public interface Condition

Condition выделяет методы мониторинга Object (wait, notify и notifyAll) в отдельные объекты, чтобы обеспечить эффект нескольких наборов ожидания на объект, объединив их с использованием произвольных реализаций Lock. Там, где Lock заменяет использование synchronized методов и инструкций, Condition заменяет использование методов мониторинга объекта.

Условные переменные (также известные как очереди условных переменных или условные переменные) предоставляют способ приостановки выполнения одного потока («ожидание») до уведомления другим потоком о том, что состояние может быть истинным. Поскольку доступ к этой общей информации о состоянии происходит в разных потоках, он должен быть защищён, поэтому с условной переменной ассоциируется какой-то замок. Основное свойство ожидания условной переменной заключается в том, что она атомарно освобождает связанный замок и приостанавливает текущий поток, так же как и Object.wait.

Экземпляр Condition изначально связан с замком. Чтобы получить экземпляр Condition для конкретного экземпляра Lock, используйте его метод newCondition().

Например, предположим, что у нас есть буфер ограниченной длины, который поддерживает методы put и take. Если попытка take выполняется на пустом буфере, то поток будет заблокирован до тех пор, пока элемент не станет доступным; если попытка put выполняется на полном буфере, то поток будет заблокирован до тех пор, пока место не станет доступным. Мы хотим поддерживать ожидание потоков put и потоков take в отдельных наборах ожидания, чтобы мы могли использовать оптимизацию, уведомляя только один поток за раз, когда элементы или места становятся доступными в буфере. Это можно сделать, используя два экземпляра Condition.

class BoundedBuffer<E> {
   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(E 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 E take() throws InterruptedException {
     lock.lock();
     try {
       while (count == 0)
         notEmpty.await();
       E x = (E) items[takeptr];
       if (++takeptr == items.length) takeptr = 0;
       --count;
       notFull.signal();
       return x;
     } finally {
       lock.unlock();
     }
   }
 }

(Класс ArrayBlockingQueue предоставляет эту функциональность, поэтому нет необходимости реализовывать этот пример класса.)

Реализация Condition может обеспечить поведение и семантику, отличную от методов мониторинга Object , например, гарантированную последовательность уведомлений или отсутствие необходимости удерживать замок при выполнении уведомлений. Если реализация предоставляет такую специализированную семантику, то реализация должна документировать эту семантику.

Обратите внимание, что экземпляры Condition — это обычные объекты, и они сами могут быть целью в инструкции synchronized, и у них могут быть вызваны собственные методы мониторинга wait и notify. Приобретение блокировки монитора экземпляра Condition или использование его методов мониторинга не имеет установленной связи с приобретением Lock, связанного с этим экземпляром Condition, или с использованием его методов ожидания и сигнализации. Рекомендуется избегать использования экземпляров Condition таким образом, за исключением, возможно, их собственной реализации.

За исключением случаев, указанных в документации, передача значения null для любого параметра приведет к тому, что будет брошено исключение NullPointerException.

Рекомендации по реализации

При ожидании условной переменной, в общем случае, допускается «ложное пробуждение», как уступка семантике базовой платформы. Это оказывает мало практического влияния на большинство прикладных программ, поскольку Condition всегда следует ожидать в цикле, проверяя предикат состояния, которого ожидается.

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

Три формы ожидания условной переменной (прерывистое, непрерывистое и временное) могут отличаться по лёгкости реализации на некоторых платформах и по производительности. В частности, может быть сложно обеспечить эти функции и поддерживать определённые семантики, такие как гарантии порядка.

Кроме того, возможность прерывания фактической приостановки потока может не всегда быть возможной для реализации на всех платформах.

Следовательно, реализация не обязана определять точно такие же гарантии или семантику для всех трёх форм ожидания, и она не обязана поддерживать прерывание фактической приостановки потока.

Реализация должна чётко документировать семантику и гарантии, предоставляемые каждым из методов ожидания, и когда реализация поддерживает прерывание приостановки потока, она должна соблюдать семантику прерывания, как определено в этом интерфейсе.

Поскольку прерывание, как правило, подразумевает отмену, и проверки на прерывание часто редки, реализация может отдавать приоритет реакции на прерывание перед обычным возвратом метода. Это верно, даже если можно показать, что прерывание произошло после другого действия, которое могло разблокировать поток. Реализация должна документировать это поведение.