É hora de descontinuar a sincronização, aguardar e notificar?

Existe um cenário único (que não seja a compatibilidade com JVMs antigas) em que o uso synchronizedé preferível ao a Lock? Alguém pode justificar o uso waitou notifysobre os sistemas mais recentes?

Existe algum algoritmo que deve usar um deles em sua implementação?

Vejo perguntas anteriores que abordaram esse assunto, mas gostaria de levar isso um pouco mais longe e realmente deprecateelas. Existem muitas armadilhas, armadilhas e advertências que foram resolvidas com as novas instalações. Eu apenas sinto que em breve será hora de marcá-los obsoletos.

java synchronization deprecation

— OldCurmudgeon
fonte

Você leu a simultaneidade Java na prática de Brian Goetz? Ele aborda bem o debate implícito vs explícito.

— Martijn Verburg

@MartijnVerburg - Infelizmente não, mas tenho um enorme respeito por seu trabalho.

— OldCurmudgeon

palavra-chave sincronizada pode ser útil com métodos estáticos simples que devem ser seguros para threads, para qualquer outra coisa que eu usaria simultaneamente. Mas esta é a minha opinião

— Kemoda

Existe algum algoritmo que deve usar um deles em sua implementação?

Quase certamente não. (Na verdade, do ponto de vista teórico, você deve ser capaz de esperar simular / notificar usando outro java.util.concurrent. . Classes. E sincronizado poderia ser substituído com operações de bloqueio explícitas ... embora você precisa ter o cuidado de desbloqueio em finallycláusulas.)

No entanto, provavelmente existem algoritmos nos quais a implementação de melhor desempenho em Java envolve o uso direto de sincronizados, com ou sem espera e notificação.

É hora de descontinuar a sincronização, aguardar e notificar?

Independentemente da resposta à pergunta anterior, a resposta é definitivamente não.

A espera / notificação pode ser (e geralmente é) usada corretamente. Em Java, a reprovação é reservada para classes e métodos que estão quebrados; isto é, onde o uso continuado deve ser corrigido com urgência. Se a Sun (e agora a Oracle) reprovasse algo tão fundamental e amplamente usado como esperar / notificar, eles estariam criando um sério problema de compatibilidade para grandes quantidades de código legado. Isso não é do interesse de ninguém.

Se você deseja se livrar da sincronização / espera / notificação no seu código, tudo bem. Mas a depreciação exige a reescrita de grandes quantidades de código multiencadeado essencialmente correto, e isso seria uma MAU IDÉIA. Os gerentes corporativos de TI e gerentes de produtos de software odiariam você por sugerir isso ...

Vale a pena ler o que "obsoleto" significa de acordo com a documentação Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

E observe também que estamos falando de coisas obsoletas que são essenciais para a linguagem Java. A preterição synchronizedtem enormes consequências.

— Stephen C
fonte

Na verdade, até onde me lembro, de acordo com o excelente livro "concorrência em Java na prática", as java.util.concurrentclasses util são realmente mais rápidas. Nos bastidores, essas classes conversam diretamente com a VM, onde, quando sincronizadas, instala um bloqueio brusco no objeto no gráfico de objetos e, portanto, afeta o desempenho global.

— akuhn

Perdoe-me @ Stephen se eu me deparar com sugerir que realmente removamos o synchronizedet. al. Estou apenas sugerindo a suspensão, que realmente diz apenas que não use isso para o novo código. Eu não sonharia em sugerir um código legado danificado, testado e comprovado, exigindo sua remoção.

— OldCurmudgeon

@ OldCurmudgeon - é uma resposta tardia, mas acho que a depreciação é muito extrema. 1) Isso significa que o recurso pode ser removido. 2) Isso implica que o recurso está quebrado, distinto de ser apenas antiquado. 3) Muitas pessoas ainda estão felizes em escrever um novo código dessa maneira ... e não há nenhuma razão forte para que não devam. 4) Existem outras maneiras, menos "na sua cara", de desencorajá-lo; por exemplo, escrevendo regras PMD ...

— Stephen C

@StephenC - Existe uma ação um pouco menos dramática que possamos tomar que acabará resultando em que eles não sejam usados ou ensinados na faculdade. Eles claramente devem ser evitados. Eu suspeito que as regras do PMD - embora seja uma boa idéia - não chegariam aos professores muito rapidamente.

— #

@StephenC Um resumo: observando os documentos Java aos quais você vinculou, não acho que a depreciação signifique que o código descontinuado está quebrado. Essa é uma razão, mas, como dizem os documentos, uma API pode ser preterida quando substituída por uma API nova e melhor (como, segundo o OP, é o caso da simultaneidade). E a concorrência de baixo nível, se não for de fato encorajar más práticas, certamente é muito propensa a erros.

— Andres F.