2009-03-04 15 views
5

Ahora, no estoy seguro si esta es una pregunta estúpida, por favor tengan paciencia conmigo si lo es.Java: ¿Qué es, en todo caso, bloqueado por métodos sincronizados aparte del objeto al que pertenecen?

El bloqueo de un objeto es "recursivo", i. mi. si dos objetos tienen referencias a un tercer objeto en sus campos y un hilo ejecuta un método sincronizado en uno de los dos, ¿puede otro hilo acceder al tercer objeto?

// a and b are some objects that implement Runnable 
// they both reference the same third object 
a.ref = c; 
b.ref = c; 

// a is run in a thread and processes some data in a loop for a long time 
// the method the loop belongs to is declared synchronized 
threadA = new Thread(a); 
threadA.start(); 

a.someSyncedMethod(); // this would block ... 
b.ref.someOtherSyncedMethod(); // ... but would this? 
a.ref.someOtherSyncedMethod(); // ... and how about this? 
+0

No es una pregunta estúpida, solo una básica. No hay problema en pedir una mejor comprensión de los fundamentos del lenguaje –

+0

Gracias. Sentí que esto debería ser obvio de alguna manera, pero todavía no lo entendí. –

Respuesta

10

Vale la pena separar los conceptos de "bloqueo" y "bloqueo de un objeto". No hay una idea real de "bloquear un objeto": hay "adquirir (y liberar)" el ​​bloqueo asociado con un objeto. Sí, suena como si estuviese pizca de algo, pero la distinción es importante porque si hablas de un objeto bloqueado, parece que ningún otro subproceso podrá cambiar nada en el objeto mientras esté bloqueado.

En su lugar, significa que ningún otro hilo podrá adquirir el mismo candado mientras se mantiene el bloqueo. No existe una relación directa entre el bloqueo y ninguno de los contenidos del objeto al que está asociado el bloqueo.

Los métodos declarados "sincronizados" adquieren el bloqueo asociado con la instancia del objeto al que pertenecen. Esto solo hace que otros métodos sincronizados en el mismo objeto esperen y las sentencias sincronizadas que se sincronizan explícitamente.

Personalmente, no me gustan los métodos sincronizados. Me gusta hacerlo más claro mediante la sincronización explícita en una variable de miembro (privada, final) que solo se utiliza para la sincronización.

+0

Sí, ayuda, pero no estoy seguro de si realmente lo tengo. ¿Es correcto que solo bloquearán aquellas llamadas que necesiten el mismo bloqueo, i. mi. llamadas a métodos sincronizados de la misma instancia, mientras que cualquier código que se bloquea en un miembro de un procederá? –

+0

Sí. Personalmente, no me gustan los métodos sincronizados. Me gusta aclararlo sincronizando explícitamente en una variable miembro (privada, final) que solo se utiliza para la sincronización. –

+0

Edité lo anterior en su publicación, espero, lo hice bien. ¡Gracias! –

1
a.someSyncedMethod(); // this would block ... 

Sólo si se marca, ya sea con el método de ejecución de ejecución de códigos ThreadA sincronizada o tienen en métodos sincronizados.

En la JVM, cada objeto posee lo que se conoce como monitor. Solo un hilo puede poseer el monitor asociado con un objeto dado a la vez. Sincronizado es el medio por el cual le dice al hilo actual que vaya a buscar el monitor antes de continuar.

También la clase en sí posee un monitor para métodos estáticos.

0

El significado de un "bloqueo" (en realidad esta variante se llama monitor) es totalmente una convención, no se aplican restricciones de acceso.

El funcionamiento se basa en que todos los objetos se comporten bien y adquieran el bloqueo correspondiente antes de acceder a los datos. Solo al encapsular este comportamiento deseado dentro de una clase con controles de acceso adecuados, puede aplicarlo para los objetos del cliente.

Cuestiones relacionadas