Чи є ці розширені / несправедливі запитання щодо інтерв'ю щодо одночасності Java? [зачинено]

Наразі це запитання не підходить для нашого формату запитань. Ми очікуємо, що відповіді будуть підкріплені фактами, посиланнями або експертними знаннями, але це питання, ймовірно, вимагатиме дискусій, аргументів, опитувань чи розширеної дискусії. Якщо ви вважаєте, що це питання можна вдосконалити та, можливо, знову відкрити, відвідайте довідковий центр для ознайомлення .

Закрито 7 років тому .

Ось кілька запитань, які я нещодавно задавав респондентам, які кажуть, що знають паралельність Java:

Поясніть небезпеку «видимості пам’яті» - спосіб JVM може переупорядкувати певні операції над змінними, незахищеними монітором і не оголошеними volatile, таким чином, щоб один потік не бачив зміни, внесені іншим потоком. Зазвичай я запитую це, показуючи код, де існує ця небезпека (наприклад, NoVisibilityприклад у Лістингу 3.1 з «Конкурсу Java на практиці» Goetz та ін.) І запитую, що не так.
Поясніть, як volatileвпливає не тільки фактична заявлена змінна volatile, але й будь-які зміни змінних, внесених потоком, перш ніж вона змінює volatileзмінну.
Чому ви можете використовувати volatileзамість цього synchronized?
Реалізуйте змінну умови за допомогою wait()та notifyAll(). Поясніть, для чого слід використовувати notifyAll(). Поясніть, чому змінну стану слід перевірити за допомогою whileциклу.

Моє запитання - це відповідні чи занадто просунуті питання, щоб запитати когось, хто каже, що знає Java одночасність?

І хоча ми до цього звертаємось, чи вважаєте ви, що від того, хто працює у спільній валюті на Java, слід очікувати, що той, хто має надмірні знання про збирання сміття на Java?

java interview concurrency

— sparc_spread
джерело

Єдине, про що я хвилююся, - це уникати потрапляння в бур’яни "запам’ятовуваних фактів", а не "навичок".

— tylerl

Ці питання здаються цілком розумними для тих, хто приймається на роботу в java, що вимагатиме високого рівня одночасності.

— Ріг

Якщо ви наймаєте на посаду, яка потребує одночасного розвитку, це лише початок. Але мені цікаво, як би ви відреагували, якби хтось відповів на ваше запитання щодо notifyAll()"Я не вірю в виконання роботи планувальника ОС, тому я використовую notify()"

— kdgregory

Я також додаю запитання щодо juc-замків, структур даних, ниток басейнів та небезпечних :-)

— Martijn Verburg

Інші говорили про складність питань. Припустимо, що вони мають відношення до проекту, переконайтеся, що до них зверніться із простим запитанням і відмовтесь від цього рядка запитань, якщо стане очевидним, що кандидат вийшов з глибини - це марно витратити свій час і ваш, а також загубить енергію інтерв'ю. Немає сенсу ставити запитання, на які ви знаєте, що вони не зможуть відповісти. Не забудьте бути готовими піти на подібну глибину щодо інших тем - тільки тому, що хтось тут слабкий, це не означає, що вони не вміють і можуть проявити себе за допомогою інших сильних сторін.

— Sean McSomething

Відповіді:

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

Також ви ставите питання про механізми синхронізації низького рівня, які були замінені здебільшого на java.util.concurrentсьогоднішній день розробкою Java; замість wait()/notify() замків віддають перевагу. Ви можете бачити, що Ефективне Java 2-е видання упустило розділ, який детально пояснив механізм очікування / сповіщення, оскільки він не вважався корисним. Також контейнер обробляє багатопотокове на більш високому рівні в більшості випадків; методи EJB є безпечними для потоків, наприклад, без будь-якого занепокоєння з боку програміста (це не означає, що програмісти не повинні знати багатопотоковість).

Насправді я бачу, що багатопотоковість - це підрозділ операційних систем, а не підрозділ мови програмування. Для того, щоб побачити, чи справді людина розуміє багатопотокові та паралельні програми програмування щодо мутексів, семафорів чи планування, слід запитати спочатку, а вже згодом, детальніше про реалізацію у певній мові програмування.

— m3th0dman
джерело

Клацніть +1 на wait () та сповістіть () коментарі - проте розробник, добре розбираючись у паралельності, знав би історію та еволюцію можливостей Java у цьому просторі (включаючи аж до F&J на Java 7).

— Мартійн Вербург

@ M3th: Останній, кого я задав ці питання, мав 10-річний досвід роботи на Java і стверджував, що знає одночасне програмування. Дякую за публікацію lockvs. wait/notify- Я знав про це lockз книги Геца, але не усвідомлював, що зараз її віддають перевагу старому. Я погоджуюся з @Martijn, хоча хтось із таким рівнем досвіду повинен знати про старіші підходи. У всякому разі, я не хочу ставити це питання ще раз (особливо, оскільки я вже відзначив його як відповідь - ви :-)), але я думаю, що хтось із 10-річним досвідом повинен мати можливість відповісти на ці запитання, ні?

— sparc_spread

@Martijn Verburg Я згоден з вами обома; хороший розробник Java (особливо той, хто говорить, що він знає одночасність) повинен знати, як використовувати функцію wait () / notify (); принаймні для цікавості щодо того, чому вони з’являються у класі Object.

— m3th0dman

@sparc_spread Програміст, який прямо в своєму резюме чітко заявляє, що він / він знає, що паралельність Java має знати відповіді (принаймні, останні 3). Що стосується рівня досвіду, як я вже сказав, імо програміст, який заявляє / бажає бути архітектором / технічним керівником \ старшим розробником і має досвід 5+ Java (бекенд, а не JSP і MVC Frameworks), повинен знати відповіді. Щодо lockvs wait/notify, то блокування є кращими, коли вам справді потрібні функції низького рівня, але в більшості випадків доступна альтернатива вищого рівня; BlockingQueue - особливо корисний.

— m3th0dman

Ці підходящі чи занадто просунуті питання, щоб запитати когось, хто каже, що знає Java одночасність?

Я б сказав, що це відносно актуальні питання. Однак вони не є "несправедливими" в тому сенсі, що вони не хитрі питання.

Дійсно, «справедливість» насправді не є релевантним критерієм. Те, що вас (як інтерв'юера) має турбувати, - це те, чи питання та ваше тлумачення відповідей вибирають найкращих кандидатів на посаду чи посади, на яких ви берете інтерв'ю. (Або кажучи інакше, чи відхиляєте ви кандидатів, що вам слід дійсно більше уваги ставитись через те, що вони не відповідають на ці питання "правильно"?)

І хоча ми до цього звертаємось, чи вважаєте ви, що від того, хто працює у спільній валюті на Java, слід очікувати, що той, хто має надмірні знання про збирання сміття на Java?

Знову ж таки, це насправді не відповідне питання. Питання, яке ви повинні задати собі, чи потрібен вам хтось, хто добре володіє збиранням сміття Java.

— Стівен С
джерело

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

— sparc_spread