È tempo di deprecare sincronizzato, attendere e notificare?

Esiste un singolo scenario (diverso dalla compatibilità con le antiche JVM) in cui synchronizedè preferibile utilizzare un Lock? Qualcuno può giustificare l'utilizzo waito notifysui sistemi più recenti?

Esiste un algoritmo che deve utilizzarne uno nella sua implementazione?

Vedo una domanda precedente che ha toccato la questione, ma vorrei approfondirla un po 'di più e in realtà sono deprecateloro. Ci sono troppe trappole, insidie e avvertenze che sono state risolte con le nuove strutture. Sento che potrebbe presto essere il momento di contrassegnarli come obsoleti.

java synchronization deprecation

— OldCurmudgeon
fonte

Hai letto la concorrenza Java in pratica di Brian Goetz? Copre bene il dibattito implicito contro il blocco esplicito lì.

— Martijn Verburg,

@MartijnVerburg - Purtroppo no, ma ho un enorme rispetto per il suo lavoro.

— OldCurmudgeon il

la parola chiave sincronizzata può essere utile con semplici metodi statici che dovrebbero essere thread-safe, per qualsiasi altra cosa vorrei usare contemporaneamente. Ma questa è la mia opinione

— Kemoda il

Esiste un algoritmo che deve utilizzarne uno nella sua implementazione?

Quasi certamente no. (In effetti, dal punto di vista teorico, si dovrebbe essere in grado di aspettare simulare / notify utilizzando altri java.util.concurrent. . Classi. E sincronizzati potrebbe essere sostituito con le operazioni di blocco esplicito ... anche se si avrebbe bisogno di stare attenti a sbloccare in finallyclausole.)

Tuttavia, ci sono probabilmente algoritmi in cui l'implementazione con le migliori prestazioni in Java comporta l'uso diretto di sincronizzato, con o senza attesa e notifica.

È tempo di deprecare sincronizzato, attendere e notificare?

Indipendentemente dalla risposta alla domanda precedente, la risposta è decisamente no.

L'attesa / notifica può essere (e spesso viene) utilizzata correttamente. In Java, la deprecazione è riservata alle classi e ai metodi non funzionanti; vale a dire dove l'uso continuato deve essere corretto con urgenza. Se Sun (e ora Oracle) deprecasse qualcosa di così fondamentale e ampiamente utilizzato come wait / notification, avrebbero creato un grave problema di compatibilità per enormi quantità di codice legacy. Questo NON è nell'interesse di nessuno.

Se vuoi sbarazzarti della sincronizzazione / attendere / notifica nel tuo codice, va bene. Ma la deprecazione richiede la riscrittura di grandi quantità di codice multi-thread essenzialmente corretto, e questa sarebbe una CATTIVA IDEA. I responsabili IT aziendali e i responsabili dei prodotti software ti odieranno per averlo suggerito ...

Vale la pena leggere cosa significa "deprecato" secondo la documentazione Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

E nota anche che stiamo parlando di deprecare cose che sono fondamentali nel linguaggio Java. L'ammortamento synchronizedha conseguenze enormi.

— Stephen C
fonte

In realtà, per quanto ricordo, secondo l'eccellente libro " java.util.concurrentConcorrenza Java in pratica", le classi util sono in realtà più veloci. Dietro le quinte, queste classi parlano direttamente con la VM, dove come sincronizzato installa un blocco smussato sull'oggetto nel grafico degli oggetti e quindi influenza le prestazioni globali.

— Akuhn

Perdonami @Stephen se mi sono imbattuto nel suggerire di rimuovere effettivamente synchronizedet. al. Sto semplicemente suggerendo la deprecazione, che in realtà dice solo di non usarlo per il nuovo codice. Non mi sognerei di suggerire di danneggiare il codice legacy provato e testato chiedendo la loro rimozione.

— OldCurmudgeon,

@OldCurmudgeon - piuttosto una risposta tardiva, ma penso che la deprecazione sia troppo estrema. 1) Significa che la funzione potrebbe essere rimossa. 2) Implica che la funzionalità sia interrotta, in quanto distinta dal semplice essere vecchio stile. 3) Molte persone sono ancora felici di scrivere un nuovo codice in quel modo ... e non c'è motivo per cui non dovrebbero. 4) Ci sono altri modi, meno "in faccia" per scoraggiarlo; ad es. scrivere regole PMD ...

— Stephen C,

@StephenC - Esiste quindi un'azione leggermente meno drammatica che alla fine si tradurrà nel fatto che non verranno utilizzati o insegnati al college. Chiaramente dovrebbero essere evitati. Sospetto che le regole del PMD - sebbene sia una buona idea - non raggiungerebbero gli insegnanti molto rapidamente.

— OldCurmudgeon,

@StephenC A nitpick: andando dai documenti Java a cui ti sei collegato, non credo che la deprecazione significhi che il codice deprecato è rotto. Questo è uno dei motivi, ma come dice la documentazione, un'API può essere deprecata quando viene sostituita da un'API più recente e migliore (come sostiene l'OP, è il caso della concorrenza). E la concorrenza di basso livello, se non addirittura incoraggiando le cattive pratiche, è certamente molto soggetta a errori.

— Andres F.