¿Es hora de desaprobar sincronizado, esperar y notificar?

13

¿Existe un escenario único (aparte de la compatibilidad con JVM antiguas) en el que synchronizedes preferible usar a Lock? ¿Alguien puede justificar el uso waito notifysobre los sistemas más nuevos?

¿Hay algún algoritmo que deba usar uno de ellos en su implementación?

Veo preguntas anteriores que tocaron este asunto, pero me gustaría llevar esto un poco más allá y, de hecho, a deprecateellas. Hay demasiadas trampas, trampas y advertencias con ellas que se han solucionado con las nuevas instalaciones. Siento que pronto será hora de marcarlos como obsoletos.

java synchronization deprecation OldCurmudgeon
fuente
44
¿Has leído la concurrencia de Java de Brian Goetz en la práctica? Cubre el debate de bloqueo implícito vs explícito muy bien allí.
Martijn Verburg el
@MartijnVerburg - Lamentablemente no, pero tengo un gran respeto por su trabajo.
OldCurmudgeon
1
la palabra clave sincronizada puede ser útil con métodos estáticos simples que deberían ser seguros para subprocesos, para cualquier otra cosa usaría concurrente. Pero esta es mi opinión
Kemoda el

Respuestas:

12

¿Hay algún algoritmo que deba usar uno de ellos en su implementación?

Casi seguro que no. (De hecho, desde el punto de vista teórico, debe ser capaz de simular espera / informen mediante otra java.util.concurrent. . Clases. Y sincronizada podría ser reemplazado con las operaciones de bloqueo explícitas ... aunque usted tendría que tener cuidado de desbloqueo en finallycláusulas)

Sin embargo, probablemente existan algoritmos en los que la implementación de mejor rendimiento en Java implique el uso directo de sincronizado, con o sin esperar y notificar.

¿Es hora de desaprobar sincronizado, esperar y notificar?

Independientemente de la respuesta a la pregunta anterior, la respuesta es definitivamente no.

La espera / notificación se puede usar (y a menudo se usa) correctamente. En Java, la desaprobación está reservada para clases y métodos que no funcionan; es decir, donde el uso continuado debe corregirse con urgencia. Si Sun (y ahora Oracle) desaprobara algo tan fundamental y tan utilizado como esperar / notificar, estarían creando un serio problema de compatibilidad para grandes cantidades de código heredado. Eso NO interesa a nadie.

Si desea deshacerse de sincronizado / esperar / notificar en su código, está bien. Pero la desaprobación exige la reescritura de grandes cantidades de código multiproceso esencialmente correcto, y eso sería una MALA IDEA. Los gerentes corporativos de TI y los gerentes de productos de software lo odiarían por sugerirlo ...

Vale la pena leer lo que significa "obsoleto" de acuerdo con la documentación de Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

Y también tenga en cuenta que estamos hablando de desaprobar cosas que son fundamentales para el lenguaje Java. Depreciar synchronizedtiene enormes consecuencias.

Stephen C
fuente
En realidad, hasta donde recuerdo, de acuerdo con el excelente libro de "concurrencia de Java en la práctica", las java.util.concurrentclases de utilidad son en realidad más rápidas. Detrás de escena, estas clases hablan directamente con la máquina virtual, donde, como sincronizado, se instala un bloqueo contundente en el objeto en el gráfico del objeto y, por lo tanto, afecta el rendimiento global.
akuhn el
Perdóname @Stephen si me encuentro sugiriendo que realmente eliminemos synchronizedet. Alabama. Simplemente estoy sugiriendo desaprobación, que en realidad solo dice que no uses esto para código nuevo. No soñaría con sugerir que el código heredado dañado y probado exija su eliminación.
OldCurmudgeon
@OldCurmudgeon: más bien una respuesta tardía, pero creo que la desaprobación es demasiado extrema. 1) Significa que la característica podría eliminarse. 2) Implica que la característica está rota, a diferencia de ser simplemente anticuada. 3) Mucha gente todavía está feliz de escribir código nuevo de esa manera ... y no hay una razón sólida para que no lo hagan. 4) Hay otras formas menos "en tu cara" de desalentarlo; por ejemplo, escribir reglas PMD ...
Stephen C
@StephenC: ¿hay una acción un poco menos dramática que podamos tomar que eventualmente resulte en que no se usen o enseñen en la universidad? Claramente se deben evitar. Sospecho que las reglas de PMD, aunque es una buena idea, no llegarían a los maestros muy rápidamente.
OldCurmudgeon 01 de
1
@StephenC Un punto crítico: siguiendo los documentos de Java con los que se vinculó, no creo que la depreciación signifique que el código en desuso está roto. Esa es una razón, pero como dicen los documentos, una API puede ser obsoleta cuando es reemplazada por una API mejor y más nueva (como, según el OP, es el caso de la concurrencia). Y la concurrencia de bajo nivel, si no fomenta las malas prácticas, es muy propensa a errores.
Andres F.