Est-il temps de déprécier synchronisé, d'attendre et de notifier?

Existe-t-il un seul scénario (autre que la compatibilité avec les anciennes machines virtuelles Java) où l'utilisation synchronizedest préférable à l'utilisation d'un Lock? Quelqu'un peut-il justifier l'utilisation waitou l' utilisation notifydes nouveaux systèmes?

Existe-t-il un algorithme qui doit utiliser l'un d'eux dans sa mise en œuvre?

Je vois une question précédente qui touchait à cette question, mais je voudrais aller un peu plus loin et en fait deprecateles. Il y a beaucoup trop de pièges, d'écueils et de mises en garde qui ont été résolus avec les nouvelles installations. J'ai juste l'impression qu'il serait peut-être bientôt temps de les marquer comme obsolètes.

java synchronization deprecation

— OldCurmudgeon
source

Avez-vous lu la concurrence Java de Brian Goetz dans la pratique? Il couvre bien le débat implicite vs explicite sur les verrous.

— Martijn Verburg

@MartijnVerburg - Malheureusement non, mais j'ai un immense respect pour son travail.

— OldCurmudgeon

le mot-clé synchronisé peut être utile avec des méthodes statiques simples qui devraient être thread-safe, pour toute autre chose que j'utiliserais simultanément. Mais c'est mon avis

— Kemoda

Existe-t-il un algorithme qui doit utiliser l'un d'eux dans sa mise en œuvre?

Certainement pas. ( En effet, du point de vue théorique, vous devriez être en mesure de simuler attente / notify à l' aide d' autres java.util.concurrent. . Classes. Et synchronisées pourrait être remplacé par Lock explicites opérations ... mais vous devez être prudent pour déverrouiller en finallyclauses.)

Cependant, il existe probablement des algorithmes où l'implémentation la plus performante en Java implique l'utilisation directe de synchronisé, avec ou sans attente et notification.

Est-il temps de déprécier synchronisé, d'attendre et de notifier?

Quelle que soit la réponse à la question précédente, la réponse est définitivement non.

L'attente / notification peut être (et est souvent) utilisée correctement. En Java, la dépréciation est réservée aux classes et méthodes qui sont cassées; c'est-à-dire lorsque l'utilisation continue doit être corrigée de toute urgence. Si Sun (et maintenant Oracle) déconseillait quelque chose d'aussi fondamental et aussi largement utilisé que l'attente / la notification, cela créerait un grave problème de compatibilité pour d'énormes quantités de code hérité. Ce n'est dans l'intérêt de personne.

Si vous voulez vous débarrasser de synchronized / wait / notify dans votre code, c'est très bien. Mais la dépréciation appelle la réécriture de grandes quantités de code multithread essentiellement correct, et ce serait une MAUVAISE IDÉE. Les responsables informatiques et les responsables de produits logiciels vous détesteraient de l' avoir suggéré ...

Il vaut la peine de lire ce que signifie "obsolète" selon la documentation Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

Et notez également que nous parlons de déprécier des éléments qui sont au cœur du langage Java. La dépréciation synchronizeda d'énormes conséquences.

— Stephen C
source

En fait, si je me souviens bien, selon l'excellent livre «Java concurrency in practice», les java.util.concurrentclasses util sont en fait plus rapides. Dans les coulisses, ces classes parlent directement à la machine virtuelle, où une synchronisation installe un verrou contondant sur l'objet dans le graphique d'objet et affecte ainsi les performances globales.

— akuhn

Pardonnez-moi @Stephen si je pense que nous supprimons réellement synchronizedet. Al. Je suggère simplement la dépréciation, ce qui ne dit vraiment que de ne pas l'utiliser pour le nouveau code. Je ne rêverais pas de suggérer des codes hérités éprouvés et éprouvés en exigeant leur suppression.

— OldCurmudgeon

@OldCurmudgeon - plutôt une réponse tardive, mais je pense que la dépréciation est trop extrême. 1) Cela signifie que la fonction pourrait être supprimée. 2) Cela implique que la caractéristique est cassée, par opposition à être simplement démodée. 3) Beaucoup de gens sont toujours heureux d'écrire du nouveau code de cette façon ... et il n'y a pas de bonne raison pour qu'ils ne le fassent pas. 4) Il existe d'autres moyens, moins «en face», de le décourager; Par exemple, écrire des règles PMD ...

— Stephen C

@StephenC - Y a-t-il alors une action un peu moins dramatique que nous pouvons entreprendre qui finira par les empêcher d'être utilisés ou enseignés à l'université. Ils doivent clairement être évités. Je soupçonne que les règles PMD - bien que ce soit une bonne idée - n'atteindraient pas les enseignants très rapidement.

— OldCurmudgeon

@StephenC Un nitpick: d'après les documents Java auxquels vous avez lié, je ne pense pas que la dépréciation signifie que le code obsolète est cassé. C'est une des raisons, mais comme le disent les documents, une API peut être déconseillée lorsqu'elle est remplacée par une API plus récente et meilleure (comme le fait valoir l'OP, c'est le cas avec la concurrence). Et la concurrence de bas niveau, si elle n'encourage pas réellement les mauvaises pratiques, est certainement très sujette aux erreurs.

— Andres F.