Essas são perguntas de entrevista avançadas / injustas relacionadas à simultaneidade Java? [fechadas]

Aqui estão algumas perguntas que fiz recentemente a entrevistados que dizem conhecer a simultaneidade Java:

Explique o risco de "visibilidade da memória" - a maneira como a JVM pode reordenar certas operações em variáveis desprotegidas por um monitor e não declaradas volatile, de modo que um encadeamento possa não ver as alterações feitas por outro encadeamento. Normalmente, pergunto a este, mostrando o código onde esse risco está presente (por NoVisibilityexemplo, o exemplo na Listagem 3.1 de "Java Concurrency in Practice" de Goetz et al) e perguntando o que está errado.
Explique como volatileafeta não apenas a variável real declarada volatile, mas também quaisquer alterações nas variáveis feitas por um encadeamento antes de alterar a volatilevariável.
Por que você pode usar em volatilevez de synchronized?
Implemente uma variável de condição com wait()e notifyAll(). Explique por que você deve usar notifyAll(). Explique por que a variável de condição deve ser testada com um whileloop.

Minha pergunta é: são apropriadas ou avançadas demais para perguntar a alguém que diz conhecer a simultaneidade Java?

E enquanto estamos nisso, você acha que alguém que trabalha com simultaneidade Java deve ter um conhecimento acima da média da coleta de lixo Java?

java interview concurrency

— sparc_spread
fonte

O único pensamento que me preocuparia é evitar entrar no mato de "fatos memorizados" em vez de "habilidades".

— tylerl

Essas perguntas parecem perfeitamente razoáveis para quem está sendo contratado para uma posição java que exigirá alto nível de simultaneidade.

— Rig

Se você está contratando um cargo que precisa de desenvolvimento simultâneo, esse é apenas o começo. Mas eu me pergunto como você reagiria se alguém respondeu a sua pergunta sobre notifyAll()com "Eu não acredito em fazer o trabalho do programador OS, então eu uso notify()"

— kdgregory

Eu também estaria adicionando Q de cerca de Locks Juc, estruturas de dados, Piscinas fio e inseguro :-)

— Martijn Verburg

Outros falaram sobre a complexidade das perguntas. Supondo que eles sejam relevantes para o projeto, certifique-se de conduzi-los com uma pergunta mais simples e abandone essa linha de questionamento se ficar óbvio que o candidato está fora de sua profundidade - é uma perda de tempo e do seu tempo e arruina a energia da entrevista. Não faz sentido fazer perguntas que você sabe que elas não serão capazes de responder. Certifique-se de estar preparado para aprofundar-se de maneira semelhante em outros tópicos - apenas porque alguém é fraco aqui não significa que não é competente e capaz de provar a si próprio por outras forças.

— 21813 Sean McSomething

Respostas:

Realmente depende se você está perguntando a um candidato com 2 anos de experiência em Java ou um com 7 anos de experiência em Java. Para um arquiteto / líder técnico / sênior, eles parecem perguntas apropriadas, mas para um júnior e talvez também para um intermediário, eles parecem meio difíceis.

Você também está fazendo perguntas sobre mecanismos de sincronização de baixo nível que foram substituídos principalmente pelo java.util.concurrentdesenvolvimento Java atual; em vez de wait()/notify() bloqueios são os preferidos. Você pode ver que o Effective Java 2nd edition descartou um capítulo que explicava o mecanismo de espera / notificação em detalhes, porque não era considerado útil. Além disso, o contêiner lida com multithreading em um nível mais alto na maioria dos casos; os métodos de um EJB são seguros para threads, por exemplo, sem nenhuma preocupação do programador (isso não significa que os programadores não devam conhecer multithreading).

Na verdade, vejo que o multithreading é uma subparte dos sistemas operacionais, e não uma subparte de uma linguagem de programação. Para verificar se uma pessoa realmente entende questões de programação paralela e multithreading sobre mutexes, semáforos ou agendamento, deve ser perguntado primeiro e somente eventualmente, detalhes sobre a implementação em uma linguagem de programação específica.

— m3th0dman
fonte

+1 nos comentários wait () e notify () - no entanto, um desenvolvedor versado em simultâneo conhecerá o histórico e a evolução dos recursos do Java nesse espaço (incluindo todo o caminho até F&J no Java 7).

— Martijn Verburg

@ M3th: A última pessoa que fiz essas perguntas tinha 10 anos de experiência em Java e alegou conhecer programação simultânea. Obrigado por postar lockvs. wait/notify- eu sabia sobre locko livro do Goetz, mas não percebi que agora era preferível ao antigo. Concordo com @Martijn, no entanto, que alguém com esse nível de experiência deve estar ciente das abordagens mais antigas. Enfim, não pretendo fazer a pergunta novamente (especialmente porque já a marquei como respondida - por você :-)), mas acho que alguém com 10 anos de experiência deve ser capaz de responder a essas perguntas, não?

— Sparc_spread

@ Martijn Verburg Concordo com vocês dois; um bom desenvolvedor Java (especialmente aquele que diz que conhece concorrência) deve saber como usar wait () / notify (); pelo menos pela curiosidade sobre por que eles aparecem na classe Object.

— M3th0dman

@sparc_spread Um programador que declara explicitamente em seu currículo que sabe que a simultaneidade Java deve saber as respostas (pelo menos os últimos 3). Em relação ao nível de experiência, como eu disse, um programador que afirma / deseja ser arquiteto / técnico / desenvolvedor sênior e possui mais de 5 anos de experiência em Java (back-end, não JSP e MVC Frameworks) deve saber as respostas. Em relação ao lockvs wait/notify, os bloqueios são preferidos quando você realmente precisa de recursos de baixo nível, mas na maioria dos casos uma alternativa de nível superior está disponível; BlockingQueue é especialmente útil.

— M3th0dman

São apropriados ou avançados demais para perguntar a alguém que diz conhecer a simultaneidade Java?

Eu diria que são perguntas relativamente avançadas. No entanto, eles não são "injustos" no sentido de que não são perguntas complicadas.

De fato, "justiça" não é realmente um critério relevante. O que você (como entrevistador) deve se preocupar é se as perguntas e sua interpretação das respostas estão selecionando os melhores candidatos para a posição ou posições para as quais você está entrevistando. (Ou, em outras palavras, você está rejeitando os candidatos que realmente deveria dar mais atenção, porque eles não responderam "corretamente" a essas perguntas?)

E enquanto estamos nisso, você acha que alguém que trabalha com simultaneidade Java deve ter um conhecimento acima da média da coleta de lixo Java?

Novamente, essa não é realmente a questão relevante. A pergunta que você deve se perguntar é se precisa de alguém que tenha um bom conhecimento da coleta de lixo do Java.

— Stephen C
fonte

Muito obrigado por esta resposta. Eu realmente gostaria de ter marcado tanto como a resposta. Agradeço o tempo que você levou para ajudar aqui.

— Sparc_spread 9/12/12