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

Вызов фабрики Set.of завершается исключением из-за повторяющегося элемента, хотя повторная вставка в обычный Set обычно не меняет его состояние. Какой контракт фабричного метода объясняет это различие?

Как трактовать результат size() у ConcurrentHashMap во время одновременных изменений?

Разберите, почему в этом коде peek работает быстрее poll, хотя обе операции обращаются к минимальному элементу очереди:

import java.util.PriorityQueue;

PriorityQueue<Integer> queue = new PriorityQueue<>();
queue.add(7);
queue.add(2);
queue.add(5);

System.out.println(queue.peek());
System.out.println(queue.poll());

При обработке записей через представление entrySet изменение объекта Map.Entry меняет исходную карту. Какой контракт представления объясняет это поведение?

На проекте нужен ограниченный LRU-кэш на стандартных коллекциях Java. Какой механизм LinkedHashMap позволяет автоматически удалять наименее недавно использованную запись?

Нужно удалить из списка все строки, начинающиеся с tmp, не ухудшая производительность при большом числе совпадений. Какой механизм реализации определяет сложность removeIf в этом коде?

import java.util.ArrayList;
import java.util.List;

List<String> files = new ArrayList<>();
for (int i = 0; i < 100_000; i++) {
    files.add(i % 2 == 0 ? "tmp-" + i : "data-" + i);
}

files.removeIf(name -> name.startsWith("tmp-"));

Как устроен итератор ConcurrentHashMap так, что он допускает параллельные изменения карты без ConcurrentModificationException?

При обходе списка через ListIterator требуется заменить текущий элемент. Какая семантика операции set позволяет сделать это без структурного изменения списка?

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

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

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

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

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

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

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

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

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

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

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

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