Многопоточность

В сценарии, где поток должен отказаться от ожидания блокировки по interrupt, почему ReentrantLock подходит лучше synchronized?

В чём риск проверять условие перед wait() без повторной проверки после пробуждения?

При неудаче CAS какой вывод делает поток о состоянии общего значения?

Объясните механизм повторного входа одного потока в уже захваченный им монитор synchronized.

В рабочей ситуации что происходит с ExecutorService после вызова shutdown()?

Представьте, что один поток создаёт объект с обычными полями и передаёт ссылку на него через несинхронизированное общее поле. Может ли другой поток увидеть ссылку, но не увидеть корректные значения этих полей?

Какую гарантию видимости получает потребитель после take() элемента, помещённого производителем в BlockingQueue?

Что гарантирует Java Memory Model потоку, который успешно дождался завершения другого потока через Thread.join()?

Возможно ли потерять обновления, если общий счётчик объявлен volatile, но несколько потоков увеличивают его?

Разберите ситуацию: один поток изменяет обычное поле, затем освобождает конкретный lock, а другой после захвата того же lock читает это поле. Какие гарантии даёт Java Memory Model?