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

В системе производители и потребители должны ожидать разные условия одной блокировки. Чем Condition при ReentrantLock принципиально отличается от wait/notify на одном мониторе?

При обновлении данных под ReentrantReadWriteLock как сохранить возможность чтения после записи, не открывая окно между блокировками?

Во время Object.wait() поток временно теряет монитор объекта или сохраняет его до пробуждения?

При чтении обычного поля long одним потоком во время записи этого поля другим потоком возможна ли атомарная ошибка чтения?

Очередь ThreadPoolExecutor заполнена, достигнут максимум потоков, а для отклонённых задач выбран CallerRunsPolicy. В каком потоке выполнится новая задача?

В сценарии с поэтапной обработкой, где число участников меняется, почему Phaser подходит лучше CountDownLatch?

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

import java.util.concurrent.*;

class Demo {
    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newSingleThreadExecutor();
        Future<?> future = pool.submit(() -> {
            throw new IllegalStateException("boom");
        });
        System.out.println("done");
        pool.shutdown();
    }
}

В следующем коде функция обновления записывает сообщение в журнал. Какой скрытый риск возникает при конкуренции нескольких потоков?

import java.util.concurrent.atomic.AtomicInteger;

class Demo {
    static final AtomicInteger value = new AtomicInteger();

    static int next() {
        return value.updateAndGet(old -> {
            System.out.println("old=" + old);
            return old + 1;
        });
    }
}

Найдена ошибка: общий список обёрнут в Collections.synchronizedList, но его перебирают без внешней синхронизации. Почему это всё ещё небезопасно?

Разберите ленивую инициализацию singleton с double-checked locking: зачем ссылке на экземпляр нужен volatile?

После успешного Future.get() какие изменения, выполненные внутри задачи, обязан увидеть вызывающий поток?

При исключении внутри synchronized-блока кто и в какой момент освобождает монитор?

Какую границу атомарности устанавливает compute для одного ключа в ConcurrentHashMap?

Два потока одновременно впервые обращаются к классу со статическим состоянием: какую гарантию даёт инициализация класса?

Имеет ли Thread.yield() гарантированный эффект для планировщика Java?

В чём различие гарантий lock-free и wait-free для многопоточного алгоритма на CAS?

Почему вызов LockSupport.unpark() до LockSupport.park() не теряется?

Опишите гарантию видимости, которую Exchanger обеспечивает после успешного двустороннего обмена потоков.

В задаче ForkJoinPool один рабочий поток вызывает join() для подзадачи: почему это не обязательно приводит к простому ожиданию бездействующего потока?

Допустим, для ReentrantLock включена честная очередность: может ли вызов tryLock() захватить блокировку, обойдя уже ожидающий поток?