example - ¿Por qué se declaran wait() y notify() en la clase Object de Java?

object tostring java

Question

¿Por qué los métodos wait() y notify() declaran en la clase Object , en lugar de la clase Thread ?

Answer 1

Algunas de las otras respuestas usan la palabra "monitor", pero ninguna explica lo que significa.

El nombre "monitor" se acuñó mucho en la década de 1970, y se refería a un objeto que tenía su propio bloqueo intrínseco y un mecanismo de espera / notificación asociado. https://en.wikipedia.org/wiki/Monitor_%28synchronization%29

Veinte años después, hubo un breve momento en el tiempo en que las computadoras de escritorio y procesadores múltiples eran nuevas, y estaba de moda pensar que la forma correcta de diseñar software para ellas consistiría en crear programas orientados a objetos en los que cada objeto fuera una monitor.

Resulta que no fue una idea tan útil, pero ese breve momento pasa exactamente cuando se inventó el lenguaje de programación Java.

Answer 2

Debido a que solo un hilo a la vez puede poseer el monitor de un objeto y este monitor es lo que los hilos están esperando o notificando. Si lee el javadoc para Object.notify() y Object.wait() se describe en detalle.

Answer 3

El mecanismo de sincronización implica un concepto: monitor de un objeto. Cuando se invoca wait (), se solicita el monitor y se suspende la ejecución adicional hasta que se adquiera el monitor o se produzca una excepción interrumpida. Cuando se invoca notify (), se libera el monitor.

Tomemos un escenario si wait () y notify () se colocaron en la clase Thread en lugar de la clase Object. En un punto del código, se llama a currentThread.wait() y luego se accede a un objeto anObject .

//.........
currentThread.wait();
anObject.setValue(1);
//.........

Cuando se invoca currentThread.wait (), se solicita un monitor de currentThread y no se realiza ninguna otra ejecución hasta que se adquiera el monitor o se produzca la excepción InterruptedException. Ahora, mientras está en estado de espera, si un método foo() de otro objeto anotherObject reside en currentThread se llama desde otro subproceso, se bloquea aunque el método llamado foo() no anObject acceso a anObject . Si se llamó al primer método wait () en anObject , en lugar del hilo en sí, otras llamadas al método (que no acceden a un anObject ) en objetos que residen en el mismo hilo no se atascarían.

Por lo tanto, llamar a los métodos wait () y notify () en la clase Object (o sus subclases) proporciona una mayor concurrencia y es por eso que estos métodos están en la clase Object, no en la clase Thread.

Answer 4

Esto se debe a que estos métodos son para la comunicación entre subprocesos y la comunicación interna ocurre mediante el uso de bloqueos, pero los bloqueos están asociados con los objetos. En consecuencia, está en la clase de objeto.

Answer 5

La razón más simple y obvia es que cualquier Objeto (no solo un hilo) puede ser el monitor de un hilo. La espera y la notificación se invocan en el monitor. El hilo que corre verifica con el monitor. Entonces, los métodos de esperar y notificar están en Object y no en Thread

Answer 6

Lea here para obtener una explicación de esperar y notificar.

Sin embargo, sería mejor evitar esto en sus aplicaciones y usar el nuevo paquete java.util.concurrent .

Answer 7

Lo pondré de una manera simple:

Para llamar a wait () o notify () necesita tener el supervisor de objetos, esto significa que wait () o notify () deben estar presentes en el bloque sincronizado

synchronized(monitorObj){
monitorObj.wait()  or even notify
}

Esa es la razón por la cual estos métodos están presentes en la clase de objeto

Answer 8

Los métodos Wait y Notify se utilizan para la comunicación entre dos Threads en Java. Entonces, la clase Object es el lugar correcto para que estén disponibles para cada objeto en Java.

Otra razón es que los Bloqueos están disponibles por Objeto. Los hilos necesitan bloquearse y esperan el bloqueo, no saben qué hilos se mantienen bloqueados, simplemente saben que el hilo está bloqueado y deben esperar al bloqueo en lugar de saber qué hilo está dentro del bloque sincronizado y pedirles que lo liberen. bloquear

Answer 9

Porque, esperas en un Objeto dado (o específicamente, su monitor) para usar esta funcionalidad.

Creo que puede estar equivocado sobre cómo funcionan estos métodos. No están simplemente en un nivel de granularidad de subprocesos, es decir, no se trata simplemente de llamar a wait() y ser despertado por la siguiente llamada a notify() . Por el contrario, siempre llama a wait() en un objeto específico y solo lo despertarán las llamadas para notify sobre ese objeto .

Esto es bueno porque de lo contrario las primitivas de concurrencia simplemente no se escalarían; sería equivalente a tener espacios de nombres globales, ya que cualquier llamada a notify() en cualquier parte de su programa podría desordenar cualquier código simultáneo, ya que activaría cualquier bloqueo de hilos en una llamada a wait() . De ahí la razón por la que los llamas sobre un objeto específico; proporciona un contexto para que el par wait- myBlockingObject.notify() funcione, por lo que cuando llama a myBlockingObject.notify() , en un objeto privado, puede estar seguro de que solo activará subprocesos que invocaron los métodos wait de su clase. Algún hilo de Spring que pueda estar esperando en otro objeto no será activado por esta llamada, y viceversa.

Editar: O para abordarlo desde otra perspectiva: supongo que a partir de su pregunta, pensó que manejaría el hilo de espera y llamaría a notify() en ese hilo para activarlo. La razón por la que no se hace de esta manera, es que tendrías que hacer muchas tareas domésticas tú mismo. El hilo que iba a esperar tendría que publicar una referencia a sí mismo en algún lugar donde otros hilos lo pudieran ver; esto debería estar correctamente sincronizado para hacer cumplir la coherencia y la visibilidad. Y cuando quiera despertar un hilo, debe obtener esta referencia, despertarla y eliminarla de donde sea que la lea. Hay mucho más andamiaje manual involucrado, y muchas más posibilidades de equivocarse con él (especialmente en un entorno concurrente) comparado con simplemente llamar a myObj.wait() en el hilo de dormir y luego a myObj.notify() en el hilo de waker.