Queste domande di intervista avanzate / sleali riguardano la concorrenza Java? [chiuso]

Ecco alcune domande che ho recentemente posto agli intervistati che affermano di conoscere la concorrenza Java:

Spiegare il pericolo della "visibilità della memoria" - il modo in cui la JVM può riordinare determinate operazioni su variabili non protette da un monitor e non dichiarate volatile, in modo tale che un thread non possa vedere le modifiche apportate da un altro thread. Di solito lo chiedo mostrando il codice in cui è presente questo pericolo (ad NoVisibilityesempio l' esempio nel Listato 3.1 da "Concorrenza in pratica Java" di Goetz et al) e chiedendo cosa non va.
Spiegare in che modo volatileinfluisce non solo sull'effettiva variabile dichiarata volatile, ma anche su eventuali modifiche alle variabili apportate da un thread prima che cambi la volatilevariabile.
Perché potresti usare volatileinvece di synchronized?
Implementare una variabile di condizione con wait()e notifyAll(). Spiega perché dovresti usare notifyAll(). Spiega perché la variabile condizione dovrebbe essere testata con un whileciclo.

La mia domanda è: sono appropriati o troppo avanzati per chiedere a qualcuno che dice di conoscere la concorrenza Java?

E mentre ci siamo, pensi che qualcuno che lavora nella concorrenza Java dovrebbe avere una conoscenza superiore alla media della raccolta di rifiuti Java?

java interview concurrency

— sparc_spread
fonte

L'unica cosa di cui mi preoccuperei è quella di evitare di entrare nelle erbacce dei "fatti memorizzati" piuttosto che delle "abilità".

— tylerl,

Queste domande sembrano perfettamente ragionevoli per chiunque venga assunto in una posizione Java che richiederà un elevato livello di concorrenza.

— Rig

Se stai assumendo una posizione che necessita di sviluppo simultaneo, questi sono solo l'inizio. Ma mi chiedo come reagiresti se qualcuno rispondesse alla tua domanda notifyAll()con "Non credo nel fare il lavoro dello scheduler del sistema operativo, quindi uso notify()"

— kdgregory

Aggiungerei anche Q's su juc Locks, strutture dati, Thread Pools e Unsafe :-)

— Martijn Verburg

Altri hanno parlato della complessità delle domande. Supponendo che siano rilevanti per il progetto, assicurati di far fronte a loro con qualche domanda più semplice e di abbandonare questa linea di domande se diventa ovvio che il candidato è fuori dalla sua profondità - è una perdita del loro tempo e del tuo e rovina l'energia dell'intervista. Non ha senso porre domande che sai che non saranno in grado di rispondere. Assicurati di essere pronto ad approfondire simili argomenti su altri argomenti - solo perché qualcuno è debole qui non significa che non siano competenti e in grado di dimostrarsi attraverso altri punti di forza.

— Sean McSomething,

Risposte:

Dipende davvero se stai chiedendo a un candidato con 2 anni di esperienza Java o uno con 7 anni di esperienza Java. Per un architetto / responsabile tecnico / senior sembrano domande appropriate ma per un junior e forse anche per un livello medio, sembrano un po 'difficili.

Inoltre stai ponendo domande sui meccanismi di sincronizzazione di basso livello che sono stati sostituiti principalmente dallo java.util.concurrentsviluppo Java attuale; anziché i wait()/notify() blocchi sono preferiti. Si può vedere che Effective Java 2nd Edition ha abbandonato un capitolo che spiega in dettaglio il meccanismo di attesa / notifica, perché non è stato considerato utile. Inoltre, il contenitore gestisce il multithreading a un livello superiore nella maggior parte dei casi; i metodi di un bean sono sicuri per i thread, ad esempio senza alcuna preoccupazione da parte del programmatore (ciò non significa che i programmatori non debbano conoscere il multithreading).

In realtà vedo che il multithreading è una sottoparte dei sistemi operativi piuttosto che una sottoparte di un linguaggio di programmazione. Per vedere se una persona capisce veramente le domande di programmazione multipla e parallela su mutex, semafori o pianificazione dovrebbero essere poste in primo luogo e solo alla fine, i dettagli sull'implementazione in un particolare linguaggio di programmazione.

— m3th0dman
fonte

+1 sui commenti wait () e notification () - tuttavia uno sviluppatore esperto in concorrenza saprebbe la storia e l'evoluzione delle capacità di Java in questo spazio (incluso fino a F&J in Java 7).

— Martijn Verburg,

@ M3th: L'ultima persona a cui ho posto queste domande ha avuto 10 anni di esperienza Java e ha affermato di conoscere la programmazione concorrente. Grazie per la pubblicazione lockvs. wait/notify- Sapevo lockdal libro Goetz ma non mi rendevo conto che ora era preferito al vecchio modo. Sono d'accordo con @Martijn anche se qualcuno con questo livello di esperienza dovrebbe essere consapevole degli approcci più vecchi. Comunque non intendo porre di nuovo la domanda (specialmente perché l'ho già contrassegnata come risposta - da te :-)) ma penso che qualcuno con 10 anni di esperienza dovrebbe essere in grado di rispondere a queste domande, no?

— sparc_spread il

@Martijn Verburg Sono d'accordo con entrambi; un buon sviluppatore Java (specialmente uno che dice di conoscere la concorrenza) dovrebbe sapere come usare wait () / notification (); almeno per la curiosità sul perché compaiano nella classe Object.

— m3th0dman,

@sparc_spread Un programmatore che afferma esplicitamente nel suo curriculum che sa che la concorrenza di Java dovrebbe conoscere le risposte (almeno gli ultimi 3). Per quanto riguarda il livello di esperienza, come ho detto, imo un programmatore che afferma / desidera essere architetto / responsabile tecnico \ sviluppatore senior e ha 5+ esperienze Java (backend, non JSP e MVC Frameworks) dovrebbe conoscere le risposte. Per quanto riguarda lockvs wait/notify, i blocchi sono preferiti quando hai davvero bisogno di funzionalità di basso livello ma nella maggior parte dei casi è disponibile un'alternativa di livello superiore; BlockingQueue è particolarmente utile.

— m3th0dman,

Sono appropriati o troppo avanzati per chiedere a qualcuno che afferma di conoscere la concorrenza Java?

Direi che sono domande relativamente avanzate. Tuttavia non sono "ingiusti", nel senso che non sono domande ingannevoli.

In effetti "l'equità" non è in realtà un criterio rilevante. Ciò di cui (come intervistatore) dovresti preoccuparti è se le domande e la tua interpretazione delle risposte sta selezionando i migliori candidati per la posizione o le posizioni per le quali stai intervistando. (O per dirla in altro modo, stai rifiutando i candidati che dovresti davvero dare più considerazione a causa della loro non risposta a queste domande "correttamente"?)

E mentre ci siamo, pensi che qualcuno che lavora nella concorrenza Java dovrebbe avere una conoscenza superiore alla media della raccolta di rifiuti Java?

Ancora una volta, questa non è davvero la domanda rilevante. La domanda che dovresti porti è se hai bisogno di qualcuno che abbia una buona conoscenza della garbage collection di Java.

— Stephen C
fonte

Grazie mille per questa risposta. Vorrei davvero che avrei potuto contrassegnare entrambi come risposta. Apprezzo il tempo che hai impiegato per aiutarti qui.

— sparc_spread