Bloqueo parcial en java
concurrency jvm (3)
¿Esto no responde a sus preguntas?
http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5
Habilita una técnica para mejorar el rendimiento de la sincronización incontenida. Un objeto está "sesgado" hacia el hilo que primero adquiere su monitor a través de un bytecode monitorenter o invocación de método sincronizado; Las operaciones subsiguientes relacionadas con el monitor realizadas por ese hilo son relativamente mucho más rápidas en las máquinas multiprocesador. Algunas aplicaciones con cantidades importantes de sincronización incontenida pueden lograr aceleraciones significativas con este indicador habilitado; Algunas aplicaciones con ciertos patrones de bloqueo pueden ver ralentizaciones, aunque se han hecho intentos para minimizar el impacto negativo.
Aunque creo que encontrarás que está activado por defecto en 1.6. Utilice la opción de diagnóstico PrintFlagsFinal para ver cuáles son los indicadores efectivos. Asegúrese de especificar -server si está buscando una aplicación de servidor porque los indicadores pueden ser diferentes:
Sigo leyendo sobre cómo el bloqueo sesgado, utilizando el indicador -XX: + UseBiasedLocking, puede mejorar el rendimiento de la sincronización incontenida. No pude encontrar una referencia a lo que hace y cómo mejora el rendimiento.
¿Alguien me puede explicar qué es exactamente o puede señalarme algunos enlaces / recursos que lo expliquen?
Esencialmente, si sus objetos están bloqueados solo por un hilo, la VM puede realizar una optimización y un "sesgo" que se oponga a ese hilo de tal manera que las operaciones atómicas subsiguientes en el objeto no incurran en costos de sincronización. Supongo que esto generalmente está orientado hacia un código demasiado conservador que realiza bloqueos en objetos sin exponerlos a otro hilo. La sobrecarga de sincronización real solo se activará una vez que otro subproceso intenta obtener un bloqueo en el objeto.
Está activado por defecto en Java 6.
-XX: + UseBiasedLocking Habilita una técnica para mejorar el rendimiento de la sincronización no controlada. Un objeto está "sesgado" hacia el hilo que primero adquiere su monitor a través de un bytecode monitorenter o invocación de método sincronizado; Las operaciones subsiguientes relacionadas con el monitor realizadas por ese hilo son relativamente mucho más rápidas en las máquinas multiprocesador. Algunas aplicaciones con cantidades importantes de sincronización incontenida pueden lograr aceleraciones significativas con este indicador habilitado; Algunas aplicaciones con ciertos patrones de bloqueo pueden ver ralentizaciones, aunque se han hecho intentos para minimizar el impacto negativo.
Me he estado preguntando acerca de los bloqueos sesgados a mí mismo.
Sin embargo, parece que los bloqueos sesgados de Java son más lentos en los procesadores nehalem de intel que en los bloqueos normales, y presumiblemente en las dos generaciones de procesadores desde nehalem. Consulte http://mechanical-sympathy.blogspot.com/2011/11/java-lock-implementations.html y aquí http://www.azulsystems.com/blog/cliff/2011-11-16-a-short-conversation-on-biased-locking
También más información aquí https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
He estado esperando que haya una manera relativamente barata de revocar un bloqueo sesgado en la inteligencia, pero estoy empezando a creer que eso no es posible. Los artículos que he visto sobre cómo se hace se basan en: 1) usar el sistema operativo para detener el hilo 2) enviar una señal, es decir, ejecutar el código en el otro hilo 3) tener puntos seguros que están garantizados para ejecutarse con bastante frecuencia en el otro hilo y esperando que se ejecute uno (que es lo que hace java). 4) tener puntos seguros similares que son una llamada a una devolución, y el otro hilo MODIFICA EL CÓDIGO a un punto de interrupción ...