Apakah pertanyaan wawancara lanjutan / tidak adil ini berkaitan dengan Java concurrency? [Tutup]

Berikut adalah beberapa pertanyaan yang baru-baru ini saya tanyakan kepada orang yang diwawancarai yang mengatakan bahwa mereka tahu Java concurrency:

Jelaskan bahaya "visibilitas memori" - cara JVM dapat menyusun ulang operasi tertentu pada variabel yang tidak dilindungi oleh monitor dan tidak dideklarasikan volatile, sehingga satu utas mungkin tidak melihat perubahan yang dilakukan oleh utas lain. Biasanya saya bertanya yang ini dengan menunjukkan kode di mana bahaya ini hadir (misalnya NoVisibilitycontoh pada Listing 3.1 dari "Java Concurrency in Practice" oleh Goetz et al) dan menanyakan apa yang salah.
Jelaskan bagaimana volatilepengaruhnya tidak hanya terhadap variabel aktual yang dideklarasikan volatile, tetapi juga setiap perubahan pada variabel yang dibuat oleh utas sebelum mengubah volatilevariabel.
Mengapa Anda menggunakan volatilebukan synchronized?
Menerapkan variabel kondisi dengan wait()dan notifyAll(). Jelaskan mengapa Anda harus menggunakannya notifyAll(). Jelaskan mengapa variabel kondisi harus diuji dengan whileloop.

Pertanyaan saya adalah - apakah ini tepat atau terlalu canggih untuk bertanya kepada seseorang yang mengatakan mereka tahu Java concurrency?

Dan sementara kita melakukannya, apakah Anda berpikir bahwa seseorang yang bekerja di Java concurrency seharusnya diharapkan memiliki pengetahuan di atas rata-rata tentang pengumpulan sampah Jawa?

java interview concurrency

— sparc_spread
sumber

Satu-satunya pemikiran yang saya khawatirkan adalah menghindari masuk ke dalam ilalang "fakta yang dihafal" daripada "keterampilan".

— tylerl

Pertanyaan-pertanyaan ini tampaknya sangat masuk akal bagi siapa saja yang dipekerjakan di posisi java yang akan membutuhkan konkurensi tingkat tinggi.

— Rig

Jika Anda mencari posisi yang membutuhkan pengembangan bersamaan, ini hanya permulaan. Tapi saya ingin tahu bagaimana Anda akan bereaksi jika seseorang menjawab pertanyaan Anda tentang notifyAll()dengan "Saya tidak percaya dalam melakukan pekerjaan scheduler OS, jadi saya menggunakan notify()"

— kdgregory

Saya juga akan menambahkan Q tentang juc Locks, struktur data, Thread Pools, dan Tidak Aman :-)

— Martijn Verburg

Yang lain telah berbicara tentang kompleksitas pertanyaan. Dengan asumsi mereka relevan dengan proyek, pastikan untuk memimpin mereka dengan beberapa pertanyaan yang lebih sederhana & tinggalkan pertanyaan ini jika sudah jelas kandidatnya berada di luar jangkauan mereka - itu adalah buang-buang waktu mereka & milik Anda dan merusak energi dari wawancara. Tidak ada gunanya mengajukan pertanyaan yang Anda tahu tidak akan bisa mereka jawab. Pastikan Anda siap untuk membahas topik lain yang sama - hanya karena seseorang lemah di sini tidak berarti mereka tidak kompeten & mampu membuktikan diri melalui kekuatan lain.

— Sean McSomething

Jawaban:

Itu benar-benar tergantung apakah Anda meminta seorang kandidat dengan 2 tahun pengalaman Java atau satu dengan 7 tahun pengalaman Java. Untuk seorang arsitek / pemimpin teknis / senior, mereka tampaknya pertanyaan yang tepat tetapi untuk junior dan mungkin juga tingkat menengah, mereka tampaknya agak sulit.

Anda juga mengajukan pertanyaan tentang mekanisme sinkronisasi tingkat rendah yang sebagian besar telah digantikan oleh java.util.concurrentperkembangan Java saat ini; bukannya wait()/notify() kunci lebih disukai. Anda dapat melihat bahwa edisi Java Efektif 2 telah menjatuhkan bab yang menjelaskan mekanisme tunggu / beri tahu secara rinci, karena itu tidak dianggap berguna. Juga, wadah menangani multithreading pada tingkat yang lebih tinggi dalam banyak kasus; metode-metode dari EJB yang aman-thread misalnya tanpa perhatian dari programmer (ini tidak berarti bahwa programmer tidak boleh tahu multithreading).

Saya sebenarnya melihat multithreading sebagai bagian dari sistem operasi daripada bagian dari bahasa pemrograman. Untuk melihat apakah seseorang benar-benar memahami pertanyaan multithreading dan pemrograman paralel tentang mutex, semaphore atau penjadwalan harus ditanyakan terlebih dahulu dan hanya pada akhirnya, rincian tentang implementasi dalam bahasa pemrograman tertentu.

— m3th0dman
sumber

Memberi +1 pada komentar wait () dan notify () - namun pengembang yang berpengalaman dalam concurrency akan mengetahui sejarah dan evolusi kemampuan Java di ruang ini (termasuk semua jalan hingga F&J di Java 7).

— Martijn Verburg

@ M3th: Orang terakhir yang saya ajukan pertanyaan-pertanyaan ini memiliki 10 tahun pengalaman Java dan mengaku tahu pemrograman bersamaan. Terima kasih telah memposting lockvs. wait/notify- Saya tahu tentang lockdari buku Goetz tetapi tidak menyadari itu sekarang lebih disukai daripada cara lama. Saya setuju dengan @ Martijn bahwa seseorang dengan tingkat pengalaman ini harus mengetahui pendekatan yang lebih lama. Pokoknya saya tidak bermaksud mengajukan pertanyaan lagi (terutama karena saya sudah menandainya sebagai jawaban - oleh Anda :-)) tapi saya pikir seseorang dengan pengalaman 10 tahun harus bisa menjawab pertanyaan-pertanyaan itu, bukan?

— sparc_spread

@ Martijn Verburg Saya setuju dengan Anda berdua; pengembang Java yang baik (terutama yang mengatakan s / dia tahu concurrency) harus tahu cara menggunakan wait () / notify (); setidaknya untuk rasa ingin tahu tentang mengapa mereka muncul di kelas Object.

— m3th0dman

@ sparc_spread Seorang programmer yang secara eksplisit menyatakan dalam resumenya bahwa dia tahu Java concurrency harus mengetahui jawabannya (setidaknya 3 terakhir). Mengenai tingkat pengalaman, seperti yang saya katakan, saya seorang programmer yang mengklaim / ingin menjadi arsitek / pemimpin teknis \ pengembang senior dan memiliki 5+ pengalaman Java (backend, bukan JSP dan MVC Frameworks) harus mengetahui jawabannya. Mengenai lockvs wait/notify, kunci lebih disukai ketika Anda benar-benar membutuhkan fitur tingkat rendah tetapi dalam kebanyakan kasus alternatif tingkat yang lebih tinggi tersedia; BlockingQueue sangat berguna.

— m3th0dman

Apakah ini tepat atau terlalu canggih untuk bertanya pada seseorang yang mengatakan mereka tahu Java concurrency?

Saya akan mengatakan mereka adalah pertanyaan yang relatif maju. Namun mereka tidak "tidak adil" dalam arti bahwa mereka tidak memperdayai pertanyaan.

Memang "keadilan" sebenarnya bukan kriteria yang relevan. Apa yang Anda (sebagai pewawancara) harus khawatirkan adalah apakah pertanyaan dan interpretasi Anda atas jawaban adalah memilih kandidat terbaik untuk posisi atau posisi yang Anda wawancarai. (Atau dengan kata lain, apakah Anda menolak kandidat yang benar - benar harus Anda pertimbangkan karena mereka tidak menjawab pertanyaan ini "dengan benar"?)

Dan sementara kita melakukannya, apakah Anda berpikir bahwa seseorang yang bekerja di Java concurrency seharusnya diharapkan memiliki pengetahuan di atas rata-rata tentang pengumpulan sampah Jawa?

Sekali lagi, itu bukan pertanyaan yang relevan. Pertanyaan yang harus Anda tanyakan pada diri sendiri adalah apakah Anda membutuhkan seseorang yang memiliki pengetahuan yang baik tentang pengumpulan sampah Jawa.

— Stephen C
sumber

Terima kasih banyak atas tanggapan ini. Saya benar-benar berharap bisa menandai keduanya sebagai jawabannya. Saya menghargai waktu yang Anda ambil untuk membantu di sini.

— sparc_spread