Программирование Java

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

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

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

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

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

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

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

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

В практической ситуации поток записал данные в обычные поля, затем передал задачу через 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 успешно заменил ссылку, хотя другой поток успел убрать объект и вернуть тот же объект. Какой риск скрывает такая ситуация?