Perché wait () e notify () sono dichiarati nella class Object di Java?

Perché i metodi wait() e notify() dichiarati nella class Object , anziché nella class Thread ?

    Perché, si aspetta su un determinato object (o in particolare sul suo monitor) per utilizzare questa funzionalità.

    Penso che potresti sbagliare su come funzionano questi metodi. Non sono semplicemente a livello di granularità del thread, cioè non si tratta solo di chiamare wait() e di essere svegliati dalla prossima chiamata a notify() . Piuttosto, si chiama sempre wait() su un object specifico, e verrà solo risvegliato dalle chiamate per notify su quell’object .

    Questo è buono perché altrimenti i primitivi della concorrenza non sarebbero scalabili; sarebbe equivalente a disporre di spazi dei nomi globali, dal momento che qualsiasi chiamata a notify() qualsiasi punto del programma potrebbe potenzialmente compromettere qualsiasi codice simultaneo in quanto risvegliare qualsiasi thread che blocca su una chiamata wait() . Da qui il motivo per cui li chiami su un object specifico; fornisce un contesto per il funzionamento della coppia wait-notify, quindi quando chiami myBlockingObject.notify() , su un object privato, puoi essere certo che sveglierai solo i thread che hanno chiamato i metodi wait nella tua class. Alcuni thread Spring che potrebbero essere in attesa su un altro object non verranno ritriggersti ​​da questa chiamata e viceversa.

    Modifica: O per affrontarlo da un’altra prospettiva: mi aspetto dalla tua domanda che pensavi di ottenere un handle per il thread in attesa e chiamare notify() su quella Thread per ritriggersrlo. Il motivo per cui non è fatto in questo modo, è che dovresti fare un sacco di pulizie da solo. Il thread in attesa avrebbe dovuto pubblicare un riferimento a se stesso da qualche parte che altri thread potevano vederlo; questo dovrebbe essere correttamente sincronizzato per rafforzare la coerenza e la visibilità. E quando vuoi risvegliare un thread devi ottenere questo riferimento, risvegliarlo e rimuoverlo da dove lo leggi. C’è molto più impalcatura manuale e molte più possibilità di sbagliare (specialmente in un ambiente concorrente) rispetto alla sola chiamata myObj.wait() nel thread dormiente e poi myObj.notify() nel thread waker.

    La ragione più semplice e ovvia è che qualsiasi object (non solo un thread) può essere il monitor di un thread. L’attesa e la notifica vengono richiamate sul monitor. Il thread in esecuzione controlla con il monitor. Quindi i metodi wait e notify sono in Object e non Thread

    Perché solo un thread alla volta può possedere il monitor di un object e questo monitor è ciò che i thread stanno aspettando o notificando. Se leggi javadoc per Object.notify() e Object.wait() è descritto in dettaglio.

    Il meccanismo di sincronizzazione implica un concetto – monitor di un object. Quando viene chiamato wait (), il monitor viene richiesto e l’ulteriore esecuzione viene sospesa fino a quando non viene acquisito il monitoraggio o si verifica InterruptedException. Quando viene chiamato notify (), il monitor viene rilasciato.

    Prendiamo uno scenario se wait () e notify () sono stati inseriti nella class Thread invece della class Object. A un punto nel codice viene chiamato anObject currentThread.wait() e quindi si accede a un object anObject .

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

    Quando viene chiamato currentThread.wait (), viene richiesto il monitoraggio di currentThread e non viene eseguita alcuna ulteriore esecuzione fino a quando non viene acquisito il monitor o si verifica InterruptedException. Ora mentre è in stato di attesa, se un metodo foo() di un altro object anotherObject risiede in currentThread viene chiamato da un altro thread, viene bloccato anche se il metodo chiamato foo() non accede a anObject . Se il primo metodo wait () è stato chiamato su anObject , invece del thread stesso, gli altri call di metodo (non accedendo a anObject ) sugli oggetti che risiedono nello stesso thread non si bloccherebbero.

    In questo modo i metodi wait () e notify () sulla class Object (o le sue sottoclassi) forniscono una maggiore concorrenza ed è per questo che questi metodi si trovano nella class Object, non nella class Thread.

    Alcune delle altre risposte usano la parola “monitor”, ma nessuna spiega cosa significa.

    Il nome “monitor” è stato coniato negli anni ’70 e si riferiva a un object che aveva il proprio blocco intrinseco e al meccanismo di attesa / notifica associato. https://en.wikipedia.org/wiki/Monitor_%28synchronization%29

    Venti anni dopo, ci fu un breve momento in cui i desktop, i computer multiprocessore erano nuovi, ed era di moda pensare che il modo giusto di progettare software per loro sarebbe creare programmi orientati agli oggetti in cui ogni object fosse un tenere sotto controllo.

    Si scopre che non è stata un’idea così utile, ma quel breve momento sembra essere esattamente quando il linguaggio di programmazione Java è stato inventato.

    Leggi qui per una spiegazione di attesa e notifica.

    Sarebbe meglio evitare questi tuttavia nelle applicazioni e utilizzare il più recente pacchetto java.util.concurrent .

    Lo metterò in un modo semplice:

    Per chiamare wait () o notify () è necessario possedere il monitor dell’object – questo significa che wait () o notify () devono essere presenti nel blocco sincronizzato

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

    Questo è il motivo per cui questi metodi sono presenti nella class dell’object

    Questo perché questi metodi sono per la comunicazione tra thread e la comunicazione interframmatica avviene utilizzando i blocchi, ma i blocchi sono associati agli oggetti. Si trova nella class dell’object.

    I metodi Wait e Notify sono utilizzati per comunicare tra due thread in Java. Quindi la class Object è il posto giusto per renderli disponibili per ogni object in Java.

    Un’altra ragione è che i blocchi sono resi disponibili in base all’object. I thread devono essere bloccati e aspettano il blocco, non sanno quali thread detengono il blocco, invece sanno solo che il blocco è trattenuto da alcuni thread e dovrebbero attendere il lock invece di sapere quale thread è all’interno del blocco sincronizzato e chiedere loro di rilasciare serratura