корректно ли будет работать код в многопоточной среде?
Anonymous Quiz
20%
да
65%
нет
14%
узнать ответ
🔥4👍2❤1
Ответ про код с ConcurrencyStorage:
Тут concurrency проблема, связанная с тем,
что ссылка на storage заново присваивается в методе fillStorage()
и нет гарантий что другой поток, который вызовет метод getValue() увидит данные,
обновленные в fillStorage();
Что бы эту проблему исправить, можно, например, сделать поле storage volatile:
private volatile ConcurrentMap<String, String> storage = new ConcurrentHashMap<>();
Тут concurrency проблема, связанная с тем,
что ссылка на storage заново присваивается в методе fillStorage()
и нет гарантий что другой поток, который вызовет метод getValue() увидит данные,
обновленные в fillStorage();
Что бы эту проблему исправить, можно, например, сделать поле storage volatile:
private volatile ConcurrentMap<String, String> storage = new ConcurrentHashMap<>();
Telegram
Java Interview Tasks
#concurrency корректно ли будет работать код в многопоточной среде?
👍6🔥2🙏1
корректно ли будет работать код в многопоточной среде?
Anonymous Quiz
22%
да
67%
нет
11%
узнать ответ
🔥3👍2🙏1
Ответ про второй код с ConcurrencyStorage2:
Тут тоже concurrency проблема, связанная с тем, что теперь поле volatile, но сама мапа не thread-safe и поэтому нет гарантий,
что другие потоки увидят данные обновленные в fillStorage();
Что бы исправить эту проблему, можно взять ConcurrentHashMap и использовать его как storage;
Тут тоже concurrency проблема, связанная с тем, что теперь поле volatile, но сама мапа не thread-safe и поэтому нет гарантий,
что другие потоки увидят данные обновленные в fillStorage();
Что бы исправить эту проблему, можно взять ConcurrentHashMap и использовать его как storage;
Telegram
Java Interview Tasks
#concurrency2 корректно ли будет работать код в многопоточной среде?
👍11🔥1🙏1
Что будет в результате выполнения кода?
Anonymous Quiz
43%
Ошибок не будет
15%
Будет рантайм ексепшн
32%
Будет ошибка компиляции
10%
Узнать ответ?
👍3🔥2🙏2😭1
Что будет в результате выполнения кода?
Anonymous Quiz
60%
Ошибок не будет
15%
Будет рантайм эксепшн
17%
Будет ошибка компиляции
8%
Узнать ответ
🔥6👍2❤1
Ответ на вопросы про List<?>:
List<?> это список элементов неизвестного типа. Он применяется в ситуациях, когда важно работать с самим списком, но конкретный тип элементов в нём не имеет значения. Из такого списка можно только извлекать значения, но нельзя добавлять новые элементы (кроме null). Поэтому в первом коде будет ошибка компиляции, а во втором будет все хорошо.
List<?> это список элементов неизвестного типа. Он применяется в ситуациях, когда важно работать с самим списком, но конкретный тип элементов в нём не имеет значения. Из такого списка можно только извлекать значения, но нельзя добавлять новые элементы (кроме null). Поэтому в первом коде будет ошибка компиляции, а во втором будет все хорошо.
Telegram
Java Interview Tasks
Что будет в результате выполнения кода?
👍13🔥3🤔1🙏1
Что напечатает строчка System.out.println(exceptionCount)?
Anonymous Quiz
31%
0
29%
1
26%
2
8%
3
6%
4
👍4🔥2🙏1
Ответ на вопрос про вставку 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 ключами или значениями.
При вставке значений в 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 ключами или значениями.
Telegram
Java Interview Tasks
Что напечатает строчка System.out.println(exceptionCount)?
👍13🔥2🙏1
Оцените по 10-ти бальной шкале Set
Anonymous Poll
33%
1
6%
2
8%
3
8%
4
19%
5
5%
6
11%
7
7%
8
5%
9
33%
10
Итак, месяц май объявляется месяцем "проверки многопоточного кода". Впереди вас ждут задания на тему многопоточности.
👍6🔥2❤1
Вопрос: может ли метод spin() не завершить свою работу, даже если метод stop() был вызван?
Anonymous Quiz
74%
да, может зависнуть
19%
нет, всегда завершится
7%
узнать ответ
👍5🔥1🤔1
Ответ на задачу на SpinTest:
Здесь приведен известный пример с зависанием цикла.
Можно ожидать, что записи в переменные в конечном итоге будут видны. Однако, согласно модели памяти Java, это не относится к чтениям и записям в поля без многопоточной семантики.
Компилятор с оптимизацией может проверить поле ready один раз, и если оно "false", сократить остальную часть цикла до "while(true)", получив бесконечный цикл.
Как можно избежать данной проблемы?
Самым правильным вариантом в данном коде будет добавление ключевого слова volatile для поля ready, таким образом мы гарантируем достижение видимости изменения поля. Все записи в volatile поля становятся видимыми в конечном итоге (eventually visible), поэтому цикл в конечном итоге завершится.
Здесь приведен известный пример с зависанием цикла.
Можно ожидать, что записи в переменные в конечном итоге будут видны. Однако, согласно модели памяти Java, это не относится к чтениям и записям в поля без многопоточной семантики.
Компилятор с оптимизацией может проверить поле ready один раз, и если оно "false", сократить остальную часть цикла до "while(true)", получив бесконечный цикл.
Как можно избежать данной проблемы?
Самым правильным вариантом в данном коде будет добавление ключевого слова volatile для поля ready, таким образом мы гарантируем достижение видимости изменения поля. Все записи в volatile поля становятся видимыми в конечном итоге (eventually visible), поэтому цикл в конечном итоге завершится.
Telegram
Java Interview Tasks
Вопрос: может ли метод spin() не завершить свою работу, даже если метод stop() был вызван?
👍9🔥4🙏1