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

12

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

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

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

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

java interview concurrency sparc_spread
источник
4
Единственная мысль, о которой я бы беспокоился, - это избегать попадания в «запомненные факты», а не в «навыки».
Tylerl
5
Эти вопросы кажутся совершенно разумными для тех, кто был нанят на должность в Java, что потребует высокого уровня параллелизма.
Рог
2
Если вы нанимаете на должность, которая требует одновременного развития, это только начало. Но мне интересно, как бы вы отреагировали, если бы кто-то ответил на ваш вопрос: notifyAll()«Я не верю в работу планировщика ОС, поэтому я использую notify()»
kdgregory
2
Я также добавил бы вопросы о juc Locks, структурах данных, пулах потоков и небезопасных :-)
Martijn Verburg
2
Другие говорили о сложности вопросов. Предполагая, что они имеют отношение к проекту, обязательно задайте им более простой вопрос и откажитесь от этой линии вопросов, если станет очевидно, что кандидат не в своей тарелке - это пустая трата его времени и вашего и разрушает энергию интервью. Нет смысла задавать вопросы, которые, как вы знаете, они не смогут ответить. Будьте готовы к тому, чтобы углубиться в подобные темы - даже если кто-то здесь слаб, это не значит, что он не компетентен и не способен проявить себя с помощью других сильных сторон.
Шон МакSomething

Ответы:

11

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

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

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

m3th0dman
источник
2
+1 к комментариям wait () и notify () - однако разработчик, хорошо разбирающийся в параллелизме, будет знать историю и эволюцию возможностей Java в этом пространстве (в том числе вплоть до F & J в Java 7).
Мартейн Вербург
@ M3th: последний человек, которому я задавал эти вопросы, имел 10-летний опыт работы на Java и утверждал, что знает параллельное программирование. Спасибо за публикацию lockпротив wait/notify- я знал об этом lockиз книги Гетца, но не понимал, что теперь она предпочтительнее старой. Я согласен с @Martijn, что кто-то с таким уровнем опыта должен знать о старых подходах. В любом случае, я не хочу снова задавать вопрос (особенно, поскольку я уже пометил его как ответ - вами :-)), но я думаю, что кто-то с 10-летним опытом должен быть в состоянии ответить на эти вопросы, нет?
sparc_spread
1
@ Martijn Verburg Я согласен с вами обоими; хороший Java-разработчик (особенно тот, который говорит, что он / она знает параллелизм) должен знать, как использовать wait () / notify (); по крайней мере, из любопытства, почему они появляются в классе Object.
m3th0dman
1
@sparc_spread Программист, который прямо заявляет в своем резюме, что он / она знает, что параллелизм Java должен знать ответы (по крайней мере, последние 3). Относительно уровня опыта, как я уже сказал, imo программист, который утверждает / хочет быть архитектором / техническим руководителем \ старшим разработчиком и имеет 5+ опыта Java (бэкэнд, а не JSP и MVC Frameworks), должен знать ответы. Что касается lockпротив wait/notify, блокировки предпочтительны, когда вам действительно нужны низкоуровневые функции, но в большинстве случаев доступна альтернатива более высокого уровня; BlockingQueue является особенно полезным.
m3th0dman
14

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

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

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

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

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

Стивен С
источник
Большое спасибо за этот ответ. Я действительно хотел бы отметить оба ответа. Я ценю время, которое вы потратили, чтобы помочь здесь.
sparc_spread