Являются ли эти расширенные / несправедливые вопросы интервью относительно параллелизма Java? [закрыто]

Вот несколько вопросов, которые я недавно задавал респондентам, которые говорят, что знают параллелизм Java:

1. Объясните опасность «видимости памяти» - способ, которым JVM может переупорядочить определенные операции с переменными, которые не защищены монитором и не объявлены volatile, так что один поток может не увидеть изменения, сделанные другим потоком. Обычно я спрашиваю об этом, показывая код, в котором присутствует эта опасность (например, NoVisibilityпример в листинге 3.1 из «Параллелизма Java на практике» Гетца и др.) И спрашиваю, что не так.
2. Объясните, как это volatileвлияет не только на фактическую объявленную переменную volatile, но также на любые изменения переменных, сделанные потоком, прежде чем он изменит volatileпеременную.
3. Почему вы можете использовать volatileвместо synchronized?
4. Реализуйте условную переменную с помощью wait()и notifyAll(). Объясните, почему вы должны использовать notifyAll(). Объясните, почему переменную условия следует проверять с помощью whileцикла.

Мой вопрос - уместны ли они или слишком продвинуты, чтобы спросить кого-то, кто говорит, что знает параллелизм Java?

И в то время как мы занимаемся этим, думаете ли вы, что кто-то, работающий в параллелизме Java, должен иметь более высокий уровень знаний о сборке мусора Java?

Это действительно зависит от того, спрашиваете ли вы кандидата с 2-летним опытом работы с Java или с 7-летним опытом работы с Java. Для архитектора / технического руководителя / старшего они кажутся правильными вопросами, но для младшего и, возможно, среднего уровня, они кажутся довольно сложными.

Также вы задаете вопрос о низкоуровневых механизмах синхронизации, которые были заменены в основном java.util.concurrentв Java-разработке на сегодняшний день; вместо wait()/notify() замков предпочтительнее. Вы можете видеть, что в Effective Java 2nd edition пропущена глава, в которой подробно объясняется механизм ожидания / уведомления, поскольку он не считается полезным. Кроме того, контейнер обрабатывает многопоточность на более высоком уровне в большинстве случаев; методы EJB являются поточно-ориентированными, например, без какой-либо заботы программиста (это не означает, что программисты не должны знать многопоточность).

Я действительно вижу, что многопоточность является частью операционных систем, а не частью языка программирования. Чтобы понять, действительно ли человек понимает многопоточность и параллельное программирование, вопросы, касающиеся мьютексов, семафоров или расписаний, следует задавать в первую очередь и только потом, подробности о реализации на конкретном языке программирования.

Они уместны или слишком продвинуты, чтобы спросить кого-то, кто говорит, что знает параллелизм Java?

Я бы сказал, что это относительно сложные вопросы. Однако они не являются «несправедливыми» в том смысле, что они не являются каверзными вопросами.

Действительно, «справедливость» на самом деле не является уместным критерием. Вы (как интервьюер) должны беспокоиться о том, выбирают ли вопросы и ваша интерпретация ответов лучших кандидатов на ту должность или должности, на которые вы проводите собеседование. (Или, другими словами, вы отвергаете кандидатов, которые действительно должны уделять больше внимания из-за того, что они не отвечают на эти вопросы «правильно»?)

И в то время как мы занимаемся этим, думаете ли вы, что кто-то, работающий в параллелизме Java, должен иметь более высокий уровень знаний о сборке мусора Java?

Опять же, это не совсем актуальный вопрос. Вопрос, который вы должны задать себе: нужен ли вам кто-то, кто хорошо знает сборку мусора Java.