#concurrency2 корректно ли будет работать код в многопоточной среде?

Ответ про второй код с ConcurrencyStorage2:
Тут тоже concurrency проблема, связанная с тем, что теперь поле volatile, но сама мапа не thread-safe и поэтому нет гарантий,
что другие потоки увидят данные обновленные в fillStorage();
Что бы исправить эту проблему, можно взять ConcurrentHashMap и использовать его как storage;

Что будет в результате выполнения кода?

Что будет в результате выполнения кода?

Ответ на вопросы про List<?>:
List<?> это список элементов неизвестного типа. Он применяется в ситуациях, когда важно работать с самим списком, но конкретный тип элементов в нём не имеет значения. Из такого списка можно только извлекать значения, но нельзя добавлять новые элементы (кроме null). Поэтому в первом коде будет ошибка компиляции, а во втором будет все хорошо.

Что напечатает строчка System.out.println(exceptionCount)?

Ответ на вопрос про вставку null в мапы:
При вставке значений в HashMap:
HashMap допускает хранение null в качестве ключей и значений. Поэтому вызовы fillData(hashMap, "1", null) и fillData(hashMap, null, "1") не приведут к исключениям.
Напротив, ConcurrentHashMap не допускает null в качестве ключей или значений:
В вызове fillData(concurrentHashMap, "1", null) будет выброшено NullPointerException, поскольку значение null нельзя вставить в ConcurrentHashMap.
В вызове fillData(concurrentHashMap, null, "1") также произойдет NullPointerException, так как ключ null не допускается.
Таким образом, каждое из двух вызовов с concurrentHashMap приведет к исключению, увеличивая счетчик exceptionCount на 1 в каждом случае.
Итого, программа напечатает 2.
Это различие между мапами надо помнить, например, если вы делаете замену в коде HashMap -> ConcurrentHashMap. При этом меняется семантика, если ваш код работает с null ключами или значениями.

Вопрос на позицию software engineer: (левый и правый ботинок стоят одинаково)

Оцените по 10-ти бальной шкале Set

Итак, месяц май объявляется месяцем "проверки многопоточного кода". Впереди вас ждут задания на тему многопоточности.

Вопрос: может ли метод spin() не завершить свою работу, даже если метод stop() был вызван?

Ответ на задачу на SpinTest:
Здесь приведен известный пример с зависанием цикла.
Можно ожидать, что записи в переменные в конечном итоге будут видны. Однако, согласно модели памяти Java, это не относится к чтениям и записям в поля без многопоточной семантики.
Компилятор с оптимизацией может проверить поле ready один раз, и если оно "false", сократить остальную часть цикла до "while(true)", получив бесконечный цикл.
Как можно избежать данной проблемы?
Самым правильным вариантом в данном коде будет добавление ключевого слова volatile для поля ready, таким образом мы гарантируем достижение видимости изменения поля. Все записи в volatile поля становятся видимыми в конечном итоге (eventually visible), поэтому цикл в конечном итоге завершится.

Вопрос: что напечатает метод read?