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

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

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

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

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

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

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

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

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

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

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

Почему рекурсивный вызов computeIfAbsent для того же ключа в ConcurrentHashMap может привести к IllegalStateException?

Разбор последствий: к чему приводит смена объекта, используемого как монитор, во время работы потоков?

Какую гарантию видимости получают обычные записи, выполненные до записи в volatile-поле, после чтения этого поля другим потоком?

Поток получает interrupt во время блокирующего ожидания: какое состояние и поведение следует ожидать после этого?

После вызова Thread.start() какие гарантии видимости получает новый поток относительно действий создавшего потока до запуска?

Сравните гарантии JMM для final-полей и обычных полей объекта, опубликованного без синхронизации.

В пуле потоков задача сохраняет данные в ThreadLocal, но не очищает их перед завершением. Какой эффект проявится при повторном использовании рабочего потока?

Зачем после оптимистичного чтения через StampedLock нужна проверка валидности stamp?

В алгоритме без блокировок CAS успешно заменил ссылку, хотя другой поток успел убрать объект и вернуть тот же объект. Какой риск скрывает такая ситуация?

Рассмотрите счётчик завершённых операций. Надёжно ли это условие запускает действие ровно один раз при достижении порога 100?

import java.util.concurrent.atomic.LongAdder;

class Progress {
    private final LongAdder completed = new LongAdder();

    void mark() {
        completed.increment();
        if (completed.sum() == 100) {
            System.out.println("Готово");
        }
    }
}