usa tutorial que para instalar index funciona elastic crear consultas como comandos java multithreading synchronization mutex

java - tutorial - Sincronizando dos veces en el mismo objeto?



para que se usa elastic search (6)

Reentrante

Los bloques sincronizados usan bloqueos de reentrada , lo que significa que si el hilo ya tiene el bloqueo, puede volver a adquirirlo sin problemas. Por lo tanto, su código funcionará como espera.

Consulte la parte inferior de la página Tutorial de Java Bloqueos y sincronización intrínsecos .

Para cotizar a partir de 2015-01 ...

Sincronización reentrante

Recuerde que un hilo no puede adquirir un bloqueo propiedad de otro hilo. Pero un hilo puede adquirir un bloqueo que ya posee. Permitir que un hilo adquiera el mismo bloqueo más de una vez habilita la sincronización de reentrada . Esto describe una situación en la que el código sincronizado, directa o indirectamente, invoca un método que también contiene código sincronizado, y ambos conjuntos de código usan el mismo bloqueo. Sin la sincronización de reentrada, el código sincronizado debería tomar muchas precauciones adicionales para evitar que un tema se bloquee.

Me preguntaba si en Java obtendría un comportamiento extraño si sincronizo dos veces en el mismo objeto.

El escenario es el siguiente

pulbic class SillyClassName { object moo; ... public void method1(){ synchronized(moo) { .... method2(); .... } } public void method2(){ synchronized(moo) { doStuff(); } } }

Ambos métodos usan el objeto y están sincronizados en él. ¿Se detendrá el segundo método cuando se llame por el primer método porque está bloqueado?

No lo creo porque es el mismo hilo, pero no estoy seguro de cualquier otro resultado extraño que pueda ocurrir.


En java, la palabra clave synchronized en un método básicamente se sincroniza en el objeto actual, por lo que en realidad está haciendo lo que sugiere arriba implícitamente.

No experimentará problemas con la sincronización en un objeto en un método y luego sincronizar en el mismo objeto en otro método porque, como usted dice, el hilo actual ya mantiene el bloqueo en ese objeto.


No hay problemas. En su ejemplo, (una vez que arregle su código para deshacerse de las advertencias de compilación que obtendrá;)), la sincronización asegura que los bloques en método1 y método2 no se ejecutarán simultáneamente.

Ese es el punto de sincronización. :)

Editar: Lo siento, partes perdidas de su pregunta, pero Phill respondió. Para resumir, un solo hilo no puede atascarse.


No, el segundo método no se detendrá si lo llama primero. No se producirán resultados extraños (excepto una ligera sobrecarga para comprobar el bloqueo. Esto no importará mucho. Con Java 6 en adelante, la velocidad de bloqueo de la JVM se ha reducido - http://java.sun.com/performance/reference/whitepapers/6_performance.html )

Por ejemplo, eche un vistazo al código fuente de java.util.Vector. Hay muchas llamadas a otros métodos sincronizados desde dentro de métodos sincronizados.


Java parece ser totalmente compatible con bloqueos anidados en un objeto por el mismo hilo. Esto significa que si un hilo tiene un bloqueo externo e interno en un objeto y otro hilo intenta encerrarse en el mismo objeto, el segundo hilo se suspenderá hasta que el primer hilo haya liberado ambos bloqueos.

Mi prueba se realizó bajo Java 6 SE.


Creo que tenemos que usar el bloqueo de reentrada para lo que estás tratando de hacer. Aquí hay un fragmento de http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html .

¿Qué queremos decir con un bloqueo reentrante? Simplemente que hay un recuento de adquisiciones asociado con el bloqueo, y si un hilo que contiene el bloqueo lo vuelve a adquirir, el recuento de adquisiciones se incrementa y el bloqueo debe liberarse dos veces para liberar realmente el bloqueo. Esto es paralelo a la semántica de sincronizado; si un hilo entra en un bloque sincronizado protegido por un monitor que el hilo ya posee, el hilo podrá continuar, y el bloqueo no se liberará cuando el hilo salga del segundo bloque sincronizado (o posterior), sino que solo se liberará. cuando sale del primer bloque sincronizado ingresó protegido por ese monitor.

Aunque no lo he intentado, supongo que si quieres hacer lo que tienes arriba, debes usar un candado de reentrada.