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

Сравните гарантии 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("Готово");
        }
    }
}

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

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

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

В коде ниже цепочка создаётся до завершения исходного этапа. Какой поток вправе выполнить тело 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();
    }
}

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

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

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

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

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();
        }
    }
}

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

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

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

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

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

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

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

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