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

В практической ситуации поток записал данные в обычные поля, затем передал задачу через ExecutorService.submit: какую гарантию видимости получает выполняющая её задача?

При передаче данных через Semaphore что обязан увидеть поток после успешного acquire(), если другой поток записал обычное поле перед release()?

В коде ниже определите причину зависания при попытке перейти от чтения к записи:

import java.util.concurrent.locks.ReentrantReadWriteLock;

class Demo {
    public static void main(String[] args) {
        ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
        lock.readLock().lock();
        try {
            lock.writeLock().lock();
            System.out.println("updated");
        } finally {
            lock.writeLock().unlock();
            lock.readLock().unlock();
        }
    }
}

Какой механизм приводит к зависанию и как корректно спроектировать такую операцию?

За счёт чего поток после notify() не гарантированно продолжает работу сразу?

Что происходит с зависимой стадией CompletableFuture, если отменить исходную незавершённую future?

Сравните CountDownLatch и CyclicBarrier для повторяющейся синхронизации нескольких фаз работы.

В коде ниже цепочка создаётся до завершения исходного этапа. Какой поток вправе выполнить тело thenApply?

import java.util.concurrent.CompletableFuture;

class Demo {
    public static void main(String[] args) throws Exception {
        CompletableFuture<String> source = new CompletableFuture<>();
        CompletableFuture<String> result = source.thenApply(value -> {
            System.out.println(Thread.currentThread().getName());
            return value.toUpperCase();
        });

        Thread producer = new Thread(() -> source.complete("ok"), "producer");
        producer.start();
        producer.join();
        result.join();
    }
}

Сопоставьте блокировку экземплярного и статического synchronized-метода: почему их одновременное выполнение не блокирует друг друга?

Представьте ThreadPoolExecutor с одним основным потоком, большим maximumPoolSize и неограниченной очередью: почему при всплеске задач пул обычно не расширяется сверх одного потока?

Можно ли считать итерацию по ConcurrentHashMap точным снимком её содержимого?

Рассмотрите счётчик завершённых операций. Надёжно ли это условие запускает действие ровно один раз при достижении порога 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("Готово");
        }
    }
}

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

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

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

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

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

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

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

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

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