¿Por qué son caros sincronizar en Java?

Question

Estoy muy nuevo en Java y leí que synchronized es "muy caro" en Java. Todo lo que quiero saber es lo que es caro y cómo es caro?

Gracias.

Answer 1

Tal vez no es tan malo como usted piensa

Lo que solía ser terrible (que es, posiblemente, por qué se lee que era "muy caro"). Estos memes pueden tardar mucho tiempo para morir a cabo

  

¿Qué tan caro es la sincronización?

     

Debido a las reglas que implican el lavado de caché e invalidación, un bloque sincronizado en el lenguaje Java es generalmente más caros que las instalaciones sección crítica que ofrece muchas plataformas, que se implementan normalmente con un atómica "prueba y establecer el bit" instrucción de máquina. Incluso cuando un programa contiene sólo un único hilo que se ejecuta en un solo procesador, una llamada al método sincronizado es aún más lento que una llamada de método de un-sincronizado. Si la sincronización requiere realmente contender por la cerradura, la penalización de rendimiento es sustancialmente mayor, ya que habrá varios interruptores de hilo y las llamadas de sistema necesarios.

     

Afortunadamente, las mejoras continuas en la JVM han mejorado tanto el rendimiento general del programa Java y reducido el coste relativo de la sincronización con cada lanzamiento, y futuras mejoras se anticipado. Además, los costes de funcionamiento de la sincronización son a menudo exageradas. Una fuente bien conocida ha citado que una llamada método sincronizado es tanto como 50 veces más lento que una llamada de método de un-sincronizado. Si bien esta afirmación puede ser cierta, sino que también es muy engañoso y ha llevado a muchos desarrolladores para evitar la sincronización incluso en los casos en que sea necesaria.

Una vez dicho esto - la programación concurrente todavía puede ser lento, pero no tanto de la misma es puramente culpa de Java ahora. Hay un equilibrio entre fina y gruesa de bloqueo. Demasiado gruesa es obviamente malo, pero es posible ser demasiado bien también, como cerraduras tienen un coste que no sea cero.

Es importante tener en cuenta el recurso en particular en disputa. los discos duros mecánicos son un ejemplo donde más hilos pueden llevar a peor rendimiento.

Answer 2

Es caro porque si está utilizando hilos, y un número de hilos tienen que pasar por una sección de código sincronizado, sólo uno de ellos se puede ejecutar a la vez.

Es como un cuello de botella.

Incluso es caro cuando se utiliza un solo hilo, porque tiene que comprobar todos modos, si se le permite funcionar.

Si se reduce el uso de segmentos sincronizado el hilo no tendrá que parar para ver si se puede ejecutar (por supuesto, no tienen que compartir datos)

Una visión general de alto nivel de cómo se pueden encontrar obras de sincronización aquí

http://img20.imageshack.us/img20/2066/monitor28synchronizatioc.png

_{Un monitor de estilo de Java}

Answer 3

Esto no es tan específica a Java. La sincronización puede ser considerado "cara" en cualquier entorno multi-hilo si no se hace correctamente. Ya sea particularmente malo en Java, no sé.

Se evita que las discusiones se ejecute concurrentemente si utilizan el mismo recurso. Pero, puesto que hacer utiliza el mismo recurso, no hay mejor opción (que se tiene que hacer).

El problema es que la gente a menudo protegen con un recurso demasiado grande un ámbito. Por ejemplo, un programa mal diseñado puede sincronizar toda una matriz de objetos en lugar de cada elemento individual de la matriz (o incluso una sección de la matriz).

Esto significaría que un hilo que intenta leer elemento 7 debe esperar a que una lectura hilo o elemento 22. No es necesario escribir. Si la granularidad de la sincronización estaban en el nivel de elemento en lugar del nivel de matriz, los dos hilos no se interfieren entre sí.

Sólo cuando dos hilos intentando acceder al mismo elemento ¿habría contención de recursos. Es por eso que la regla general es sólo para proteger un recurso tan pequeño como sea posible (sujeto a limitaciones en el número de sincronizaciones, por supuesto).

Pero, para ser honesto, no importa lo caro que es, si la alternativa es la corrupción de datos debido a dos hilos que luchan sobre un único recurso. Escribir correctamente su solicitud y sólo preocuparse de los problemas de rendimiento, siempre y cuando aparecen ( "hacer que funcione primera después que funcione rápido" es un mantra de mis favoritas).

Answer 4

Este artículo href="http://www.ibm.com/developerworks/library/j-threads1.html" rel="noreferrer"> más en IBM en realidad resume muy bien los puntos principales detrás de sincronización.

  

Debido a las reglas que implican el lavado de caché e invalidación, un bloque sincronizado en el lenguaje Java es generalmente más caros que las instalaciones sección crítica que ofrece muchas plataformas, que se implementan normalmente con un atómica "prueba y establecer el bit" instrucción de máquina. Incluso cuando un programa contiene sólo un único hilo que se ejecuta en un solo procesador, una llamada al método sincronizado es aún más lento que una llamada de método no sincronizado. Si la sincronización requiere realmente contender por la cerradura, la penalización de rendimiento es sustancialmente mayor, ya que habrá varios interruptores de hilo y las llamadas de sistema necesarios.

Answer 5

Las otras respuestas dan un buen nivel de detalle técnico que no voy a tratar de replicar.

Lo que haré es aconsejarle para comprobar las fechas de los artículos (así como la competencia implícita y el conocimiento del autor). Sincronización en Java fue muy lento en las JVM anteriores. Sin embargo, se ha mejorado mucho recientemente, de tal manera que la sincronización uncontended es mucho más rápido de lo que piensa, y la sincronización uncontended ha mejorado también.

Eso sí, esta pregunta posiblemente no importa - si necesita sincronizar para garantizar la corrección, necesidad para sincronizar para garantizar la corrección. Las únicas veces que se puede ver la velocidad siendo un problema es si estaban considerando la creación de una aplicación lockless lugar (con el muy eficiente y complejo java.util.concurrent.locks.AbstractQueuedSynchronizer ), o tal vez considerar el uso de otro idioma para su tarea en su lugar.

En general creo que la mejor conclusión es que la sincronización es generalmente lo suficientemente rápido para usar en una primera iteración. Al igual que con todos los problemas de rendimiento, código para mayor claridad y exactitud en un primer momento y sólo optimizar lo que se mide a ser una parte más costosa de su aplicación. Normalmente, este no será el coste de sincronización *.