anchor.diff:  
   === Расскажите о взаимодействии synchronized/Object.wait()/.notify()/.notifyAll()
   
  -Каждый монитор имеет механизм ожидания и пробуждения. После того как поток захватил монитор, он может обнаружить, что условие для продолжения работы еще не наступило (скажем, данные еще не готовы). В этом случае хочется не постоянно проверять условие (при этом отпуская и захватывая монитор, чтобы дать другому потоку шанс изменить состояние условия), а уснуть, отдать монитор и получить нотификацию, когда условие будет выполнено. Эта функциональность достигается с помощью методов `wait`, `notify` и `notifyAll`. После того как поток захватил монитор и вошел в критическую секцию, организованную с помощью `synchronized`, он может вызывать метод `wait`. В этом случае он перейдет в wait-set монитора и отпустит монитор. При этом поток заблокируется и перейдет в состояние _WAITING_. Другой поток может захватить монитор и войти в критическую секцию, выполнить определенные действия и вызвать метод `notify` или `notifyAll`. После того как один из этих методов вызван, поток ждущий на событие, удаляется из wait-set монитора и переходит в состояние _BLOCKING_ и пытается захватить монитор. После того, как поток, который вызвал `notify` освобождает монитор, блокирующий поток захватывает монитор и переходит в состояние _RUNNABLE_.
  -
  -`notify` от `notifyAll` отличается тем, что первый пробуждает один из потоков в списке ожидания, в тоже время как последний пробуждает все потоки. Почти всегда более разумно всегда вызывать `notifyAll`, т.к. вызов этого метода дает шанс всем потокам получить монитор и он работает правильно в независимости от количества потоков в списке ожидания.
  +Каждый монитор имеет механизм ожидания и пробуждения. После того как поток захватил монитор, он может обнаружить, что условие для продолжения работы еще не наступило (скажем, данные еще не готовы). В этом случае хочется не постоянно проверять условие (при этом отпуская и захватывая монитор, чтобы дать другому потоку шанс изменить состояние условия), а уснуть, отдать монитор и получить нотификацию, когда условие будет выполнено. Эта функциональность достигается с помощью методов `wait`, `notify` и `notifyAll`. После того как поток захватил монитор и вошел в критическую секцию, организованную с помощью `synchronized`, он может вызывать метод `wait`. В этом случае он перейдет в wait-set монитора и отпустит монитор. При этом поток заблокируется и перейдет в состояние _WAITING_. Другой поток может захватить монитор и войти в критическую секцию, выполнить определенные действия и вызвать метод `notify` или `notifyAll`. После того как один из этих методов вызван, поток ждущий на событие, удаляется из wait-set монитора и переходит в состояние _BLOCKING_ и пытается захватить монитор. После того, как поток, который вызвал `notify` освобождает монитор, блокирующий поток захватывает монитор и переходит в состояние _RUNNABLE_. `notify` от `notifyAll` отличается тем, что первый пробуждает один из потоков в списке ожидания, в тоже время как последний пробуждает все потоки. Почти всегда более разумно всегда вызывать `notifyAll`, т.к. вызов этого метода дает шанс всем потокам получить монитор и он работает правильно в независимости от количества потоков в списке ожидания.
   
   === Реализуйте ограниченную блокирующую очередь на synchronized/Object.wait()/.notify()/.notifyAll()
   
  
positive.code: 
  === Почему TransferQueue НЕ BlockingQueue?
  
  Вообще-то `TransferQueue` является `BlockingQueue`, потому что наследует этот интерфейс. Если вопрос про различия, то `TransferQueue` позволяет не просто положить элемент в очередь, а также заставить потока-поставщика подождать, пока не появится свободный потребитель. Также есть метод `tryTransfer`, который позволяет не класть элемент в очередь, если нет свободного потребителя.
negative.code: 
  === Какие гарантии на работу с volatile?
  
  Запись в volatile поле _happens-before_ чтения из volatile поля. Соответственно, поток читающий из volatile поля гарантировано увидит корректное значение записи в это поля (а также всех предыдущих записей в потоке,изменившем это поле). Компилятору также запрещену переупорядочивать инструкции, которые работают с volatile полями с другими инструкциями. То есть JMM гарантирует, что записи в потоке A, которые произошли до записи в volatile-поле, произошли и видимы для потока B, который читает это поле. 
  
  === Какие гарантии на работу с final?
  
  