Java: Notify () vs. NotifyAll () di nuovo

Se si cerca su Google "differenza tra notify()e notifyAll()", verranno visualizzate molte spiegazioni (lasciando da parte i paragrafi javadoc). Tutto si riduce al numero di thread in attesa che si stanno svegliando: uno dentro notify()e tutti dentro notifyAll().

Tuttavia (se capisco bene la differenza tra questi metodi), viene sempre selezionato solo un thread per un'ulteriore acquisizione del monitor; nel primo caso quello selezionato dalla VM, nel secondo caso quello selezionato dallo scheduler del thread di sistema. Le esatte procedure di selezione per entrambi (nel caso generale) non sono note al programmatore.

Qual è la differenza utile tra notify () e notifyAll () allora? Mi sto perdendo qualcosa?

Tuttavia (se capisco bene la differenza tra questi metodi), viene sempre selezionato solo un thread per un'ulteriore acquisizione del monitor.

Questo non è corretto o.notifyAll()riattiva tutti i thread bloccati nelle o.wait()chiamate. I thread possono tornare solo o.wait()uno per uno, ma ognuno avrà il proprio turno.

In poche parole, dipende dal motivo per cui i tuoi thread sono in attesa di essere avvisati. Vuoi dire a uno dei thread in attesa che è successo qualcosa o vuoi raccontarli tutti allo stesso tempo?

In alcuni casi, tutti i thread in attesa possono eseguire azioni utili al termine dell'attesa. Un esempio potrebbe essere un insieme di thread in attesa del completamento di un determinato compito; una volta terminata l'attività, tutti i thread in attesa possono continuare con la propria attività. In tal caso, dovresti utilizzare notificationAll () per riattivare tutti i thread in attesa contemporaneamente.

Un altro caso, ad esempio il blocco reciprocamente esclusivo, solo uno dei thread in attesa può fare qualcosa di utile dopo essere stato avvisato (in questo caso acquisire il blocco). In tal caso, preferiresti usare notify () . Se correttamente implementato, è possibile utilizzare NotifyAll () anche in questa situazione, ma si risveglierebbero inutilmente thread che non possono comunque fare nulla.

In molti casi, il codice per attendere una condizione verrà scritto come un ciclo:

synchronized(o) {
    while (! IsConditionTrue()) {
        o.wait();
    }
    DoSomethingThatOnlyMakesSenseWhenConditionIsTrue_and_MaybeMakeConditionFalseAgain();
}

In questo modo, se una o.notifyAll()chiamata risveglia più di un thread in attesa e il primo a tornare dalle o.wait()marche lascia la condizione nel falso stato, gli altri thread che sono stati risvegliati torneranno in attesa.

Chiaramente, notifyriattiva (qualsiasi) un thread nel set di attesa, notifyAllriattiva tutti i thread nel set di attesa. La seguente discussione dovrebbe chiarire ogni dubbio. notifyAlldovrebbe essere usato la maggior parte del tempo. Se non si è sicuri di quale utilizzare, utilizzare notifyAll. Si prega di consultare la spiegazione che segue.

Leggi attentamente e capisci. Vi prego di inviarmi una e-mail se avete domande.

Guarda produttore / consumatore (il presupposto è una classe ProducerConsumer con due metodi). È ROTTO (perché usa notify) - sì PU MAY funzionare - anche la maggior parte delle volte, ma può anche causare deadlock - vedremo perché:

public synchronized void put(Object o) {
    while (buf.size()==MAX_SIZE) {
        wait(); // called if the buffer is full (try/catch removed for brevity)
    }
    buf.add(o);
    notify(); // called in case there are any getters or putters waiting
}

public synchronized Object get() {
    // Y: this is where C2 tries to acquire the lock (i.e. at the beginning of the method)
    while (buf.size()==0) {
        wait(); // called if the buffer is empty (try/catch removed for brevity)
        // X: this is where C1 tries to re-acquire the lock (see below)
    }
    Object o = buf.remove(0);
    notify(); // called if there are any getters or putters waiting
    return o;
}

IN PRIMO LUOGO,

Perché abbiamo bisogno di un ciclo while che circonda l'attesa?

Abbiamo bisogno di un whileciclo nel caso in cui otteniamo questa situazione:

Il consumatore 1 (C1) inserisce il blocco sincronizzato e il buffer è vuoto, quindi C1 viene messo nel set di attesa (tramite la waitchiamata). Il consumatore 2 (C2) sta per immettere il metodo sincronizzato (al punto Y sopra), ma il produttore P1 inserisce un oggetto nel buffer e successivamente chiama notify. L'unico thread in attesa è C1, quindi viene svegliato e ora tenta di riacquistare il blocco dell'oggetto nel punto X (sopra).

Ora C1 e C2 stanno tentando di acquisire il blocco della sincronizzazione. Uno di questi (non deterministico) viene scelto ed entra nel metodo, l'altro viene bloccato (non in attesa - ma bloccato, nel tentativo di acquisire il blocco sul metodo). Diciamo che C2 ottiene prima il blocco. C1 sta ancora bloccando (cercando di acquisire il blocco su X). C2 completa il metodo e rilascia il blocco. Ora, C1 acquisisce il blocco. Indovina un po ', per fortuna abbiamo un whileloop, perché C1 esegue il controllo del loop (guard) e gli viene impedito di rimuovere un elemento inesistente dal buffer (C2 lo ha già!). Se non avessimo un while, otterremmo un IndexArrayOutOfBoundsExceptioncome C1 tenta di rimuovere il primo elemento dal buffer!

ADESSO,

Ok, ora perché abbiamo bisogno di notifica All?

Nell'esempio produttore / consumatore sopra sembra che possiamo cavarcela notify. Sembra così, perché possiamo dimostrare che le guardie sui circuiti di attesa per produttore e consumatore si escludono a vicenda. Cioè, sembra che non possiamo avere un thread in attesa nel putmetodo così comeget metodo, perché, affinché ciò sia vero, allora dovrebbe essere vero quanto segue:

buf.size() == 0 AND buf.size() == MAX_SIZE (supponiamo che MAX_SIZE non sia 0)

TUTTAVIA, questo non è abbastanza buono, ABBIAMO BISOGNO di usare notifyAll . Vediamo perché ...

Supponiamo di avere un buffer di dimensione 1 (per rendere l'esempio facile da seguire). I seguenti passaggi ci portano a un punto morto. Si noti che QUALSIASI momento un thread viene svegliato con notifica, può essere selezionato in modo non deterministico dalla JVM, ovvero qualsiasi thread in attesa può essere svegliato. Si noti inoltre che quando più thread bloccano l'accesso a un metodo (ovvero tentando di acquisire un blocco), l'ordine di acquisizione può essere non deterministico. Ricorda anche che un thread può essere solo in uno dei metodi alla volta: i metodi sincronizzati consentono a un solo thread di eseguire (cioè mantenere il blocco di) qualsiasi metodo (sincronizzato) nella classe. Se si verifica la seguente sequenza di eventi - risultati deadlock:

PASSAGGIO 1:
- P1 inserisce 1 carattere nel buffer

PASSAGGIO 2:
- P2 tentativi put- controlla il ciclo di attesa - già un carattere - attende

PASSAGGIO 3:
- Tentativi P3put - verifica il ciclo di attesa - già un carattere - attende

PASSAGGIO 4:
- C1 tenta di ottenere 1 carattere
- C2 tenta di ottenere 1 carattere - blocchi all'entrata nel getmetodo
- C3 tenta di ottenere 1 carattere - blocchi all'accesso al getmetodo

PASSO 5:
- C1 sta eseguendo il getmetodo - ottiene il carattere, chiama notify, esce dal metodo
- Il notifyP2 si sveglia
- MA, C2 entra nel metodo prima che P2 possa (P2 deve riacquisire il blocco), quindi P2 blocca quando si accede al putmetodo
- C2 controlla il ciclo di attesa, non più caratteri nel buffer, quindi attende
- C3 inserisce il metodo dopo C2, ma prima di P2, controlla il ciclo di attesa, non più caratteri nel buffer, quindi attende

PASSAGGIO 6:
- ADESSO: c'è P3, C2 e C3 in attesa!
- Infine P2 acquisisce il blocco, inserisce un carattere nel buffer, chiama la notifica, esce dal metodo

PASSAGGIO 7:
- La notifica di P2 attiva P3 (ricordare che è possibile riattivare qualsiasi thread)
- P3 verifica la condizione del ciclo di attesa, nel buffer è già presente un carattere, quindi attende.
- NON PIÙ FILETTI PER CHIAMARE NOTIFICARE E TRE FILETTI PERMANENTAMENTE SOSPESO!

SOLUZIONE: sostituire notifycon notifyAllnel codice produttore / consumatore (sopra).

Differenze utili:

• Usa un avviso () se tutti i thread in attesa sono intercambiabili (l'ordine in cui si riattivano non ha importanza) o se hai sempre e solo un thread in attesa. Un esempio comune è un pool di thread utilizzato per eseguire lavori da una coda: quando viene aggiunto un lavoro, uno dei thread viene avvisato di riattivarsi, eseguire il lavoro successivo e tornare in sospensione.

• Utilizzare notifyAll () per altri casi in cui i thread in attesa potrebbero avere scopi diversi e dovrebbero essere in grado di essere eseguiti contemporaneamente. Un esempio è un'operazione di manutenzione su una risorsa condivisa, in cui più thread sono in attesa del completamento dell'operazione prima di accedere alla risorsa.

Penso che dipenda da come vengono prodotte e consumate le risorse. Se sono disponibili 5 oggetti di lavoro contemporaneamente e si hanno 5 oggetti di consumo, sarebbe opportuno riattivare tutti i thread utilizzando NotifyAll () in modo che ognuno possa elaborare 1 oggetto di lavoro.

Se hai a disposizione un solo oggetto di lavoro, che senso ha risvegliare tutti gli oggetti di consumo per correre per quell'oggetto? Il primo che controlla il lavoro disponibile lo otterrà e tutti gli altri thread controlleranno e scopriranno che non hanno nulla da fare.

Ho trovato un'ottima spiegazione qui . In breve:

Il metodo notify () viene generalmente utilizzato per i pool di risorse , dove esiste un numero arbitrario di "consumatori" o "lavoratori" che prendono risorse, ma quando una risorsa viene aggiunta al pool, solo uno dei consumatori o dei lavoratori in attesa può trattare con esso. Il metodo notifyAll () è effettivamente utilizzato nella maggior parte degli altri casi. In senso stretto, è necessario comunicare ai camerieri una condizione che potrebbe consentire a più camerieri di procedere. Ma questo è spesso difficile da sapere. Quindi, come regola generale, se non si dispone di una logica particolare per l'utilizzo di notify (), è probabile che si debba utilizzare notifyAll () , poiché spesso è difficile sapere esattamente quali thread saranno in attesa su un determinato oggetto e perché.

Si noti che con le utilità di concorrenza è anche possibile scegliere tra signal()e signalAll()poiché questi metodi vengono chiamati lì. Quindi la domanda rimane valida anche conjava.util.concurrent .

Doug Lea solleva un punto interessante nel suo famoso libro : se notify()e Thread.interrupt()accade allo stesso tempo, la notifica potrebbe effettivamente perdersi. Se ciò può accadere e ha implicazioni drammatiche, notifyAll()è una scelta più sicura anche se si paga il prezzo dell'overhead (svegliare troppi thread per la maggior parte del tempo).

Breve riassunto:

Preferisci sempre notifyAll () rispetto a notify () a meno che tu non abbia un'applicazione massicciamente parallela in cui un gran numero di thread fa la stessa cosa.

Spiegazione:

notify () [...] sveglia un singolo thread. Dato che notification () non consente di specificare il thread che è stato risvegliato, è utile solo in applicazioni massicciamente parallele, vale a dire programmi con un numero elevato di thread, tutti con compiti simili. In tale applicazione, non ti interessa quale thread viene svegliato.

fonte: https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html

Confronta Notify () con NotifyAll () nella situazione sopra descritta: un'applicazione massicciamente parallela in cui i thread stanno facendo la stessa cosa. Se in questo caso si chiama notificationAll () , notifyAll () indurrà il risveglio (ovvero la pianificazione) di un numero enorme di thread, molti dei quali inutilmente (poiché solo un thread può effettivamente procedere, vale a dire il thread a cui verrà concesso il monitorare l'oggetto wait () , notify () o notifyAll () è stato chiamato), quindi sprecando risorse di elaborazione.

Pertanto, se non si dispone di un'applicazione in cui un numero enorme di thread fa la stessa cosa contemporaneamente, preferire notifyAll () rispetto a notification () . Perché? Perché, come altri utenti hanno già risposto in questo forum, notifica ()

riattiva un singolo thread in attesa sul monitor di questo oggetto. [...] La scelta è arbitraria e si verifica a discrezione dell'attuazione.

fonte: API Java SE8 ( https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#notify-- )

Immagina di avere un'applicazione per il consumatore del produttore in cui i consumatori sono pronti (cioè aspettano () ing) a consumare, i produttori sono pronti (cioè aspettano () ing) per produrre e la coda degli articoli (da produrre / consumare) è vuota. In tal caso, notification () potrebbe svegliare solo i consumatori e mai i produttori perché la scelta che viene svegliata è arbitraria . Il ciclo del consumatore-produttore non farebbe alcun progresso, sebbene produttori e consumatori siano pronti a produrre e consumare, rispettivamente. Invece, un consumatore viene svegliato (ovvero lasciando lo stato wait () ), non toglie un oggetto dalla coda perché è vuoto e avvisa () un altro consumatore di procedere.

Al contrario, notificationAll () risveglia sia i produttori che i consumatori. La scelta programmata dipende dallo scheduler. Naturalmente, a seconda dell'implementazione dello scheduler, lo scheduler potrebbe anche programmare solo i consumatori (ad esempio se si assegnano ai thread dei consumatori una priorità molto alta). Tuttavia, il presupposto qui è che il pericolo dello scheduler che pianifica solo i consumatori sia inferiore al pericolo che la JVM risvegli solo i consumatori perché qualsiasi programmatore ragionevolmente implementato non prende solo decisioni arbitrarie . Piuttosto, la maggior parte delle implementazioni dello scheduler fanno almeno qualche sforzo per prevenire la fame.

Ecco un esempio Eseguirlo. Quindi modificare uno dei notifyAll () in notification () e vedere cosa succede.

Classe ProducerConsumerExample

public class ProducerConsumerExample {

    private static boolean Even = true;
    private static boolean Odd = false;

    public static void main(String[] args) {
        Dropbox dropbox = new Dropbox();
        (new Thread(new Consumer(Even, dropbox))).start();
        (new Thread(new Consumer(Odd, dropbox))).start();
        (new Thread(new Producer(dropbox))).start();
    }
}

Classe Dropbox

public class Dropbox {

    private int number;
    private boolean empty = true;
    private boolean evenNumber = false;

    public synchronized int take(final boolean even) {
        while (empty || evenNumber != even) {
            try {
                System.out.format("%s is waiting ... %n", even ? "Even" : "Odd");
                wait();
            } catch (InterruptedException e) { }
        }
        System.out.format("%s took %d.%n", even ? "Even" : "Odd", number);
        empty = true;
        notifyAll();

        return number;
    }

    public synchronized void put(int number) {
        while (!empty) {
            try {
                System.out.println("Producer is waiting ...");
                wait();
            } catch (InterruptedException e) { }
        }
        this.number = number;
        evenNumber = number % 2 == 0;
        System.out.format("Producer put %d.%n", number);
        empty = false;
        notifyAll();
    }
}

Classe di consumo

import java.util.Random;

public class Consumer implements Runnable {

    private final Dropbox dropbox;
    private final boolean even;

    public Consumer(boolean even, Dropbox dropbox) {
        this.even = even;
        this.dropbox = dropbox;
    }

    public void run() {
        Random random = new Random();
        while (true) {
            dropbox.take(even);
            try {
                Thread.sleep(random.nextInt(100));
            } catch (InterruptedException e) { }
        }
    }
}

Classe di produzione

import java.util.Random;

public class Producer implements Runnable {

    private Dropbox dropbox;

    public Producer(Dropbox dropbox) {
        this.dropbox = dropbox;
    }

    public void run() {
        Random random = new Random();
        while (true) {
            int number = random.nextInt(10);
            try {
                Thread.sleep(random.nextInt(100));
                dropbox.put(number);
            } catch (InterruptedException e) { }
        }
    }
}

Da Joshua Bloch, lo stesso Guru Java nella seconda edizione di Effective Java:

"Articolo 69: preferire le utilità di concorrenza per attendere e notificare".

Spero che questo chiarisca alcuni dubbi.

notify () : il metodo notify () attiva un thread in attesa del blocco (il primo thread che ha chiamato wait () su quel blocco).

notifyAll () : il metodo notifyAll () riattiva tutti i thread in attesa del blocco; la JVM seleziona uno dei thread dall'elenco dei thread in attesa del blocco e riattiva quel thread.

Nel caso di un singolo thread in attesa di un blocco, non vi è alcuna differenza significativa tra notify () e notifyAll (). Tuttavia, quando è presente più di un thread in attesa del blocco, sia in notification () che notifyAll (), il thread esatto che è stato attivato è sotto il controllo di JVM e non è possibile controllare a livello di programmazione il riattivazione di un thread specifico.

A prima vista, sembra che sia una buona idea chiamare solo notification () per riattivare un thread; potrebbe sembrare inutile svegliare tutti i thread. Tuttavia, il problema con notify () è che il thread svegliato potrebbe non essere quello adatto per essere risvegliato (il thread potrebbe essere in attesa di qualche altra condizione, oppure la condizione non è ancora soddisfatta per quel thread ecc.). In tal caso , la notifica () potrebbe andare persa e nessun altro thread si risveglierà potenzialmente portando a un tipo di deadlock (la notifica viene persa e tutti gli altri thread sono in attesa di notifica — per sempre).

Per evitare questo problema , è sempre meglio chiamare notificationAll () quando c'è più di un thread in attesa di un blocco (o più di una condizione per l'attesa). Il metodo notifyAll () attiva tutti i thread, quindi non è molto efficiente. tuttavia, questa perdita di prestazioni è trascurabile nelle applicazioni del mondo reale.

Esistono tre stati per un thread.

1. ATTENDERE: il thread non utilizza alcun ciclo della CPU
2. BLOCCATO - Il thread è bloccato nel tentativo di acquisire un monitor. È possibile che stia ancora utilizzando i cicli della CPU
3. RUNNING - Il thread è in esecuzione.

Ora, quando viene chiamato un notification (), JVM seleziona un thread e li sposta nello stato BLOCCATO e quindi nello stato RUNNING poiché non vi è competizione per l'oggetto monitor.

Quando viene chiamato a notificationAll (), JVM seleziona tutti i thread e li sposta tutti nello stato BLOCCATO. Tutti questi thread otterranno il blocco dell'oggetto su una priorità. Il thread che è in grado di acquisire prima il monitor sarà in grado di passare prima allo stato RUNNING e così via.

Sono molto sorpreso che nessuno abbia menzionato il famigerato problema del "risveglio perduto" (cercalo su Google).

Fondamentalmente:

1. se hai più thread in attesa sulla stessa condizione e,
2. più thread che possono farti passare dallo stato A allo stato B e,
3. più thread che possono farti passare dallo stato B allo stato A (di solito gli stessi thread come in 1.) e,
4. il passaggio dallo stato A a B dovrebbe notificare le discussioni in 1.

POI dovresti usare avvisare Tutti a meno che tu non abbia garanzie dimostrabili che l'impossibilità di svegliarti sia impossibile.

Un esempio comune è una coda FIFO simultanea in cui: più accodatori (1. e 3. sopra) possono passare la coda da vuoti a vuoti più dequeuers (2. sopra) possono attendere la condizione "la coda non è vuota" vuota -> non vuoto dovrebbe avvisare i dequeuers

È possibile scrivere facilmente un'interlacciamento di operazioni in cui, a partire da una coda vuota, interagiscono 2 accendini e 2 dequeuers e 1 accendino rimarrà inattivo.

Questo è probabilmente un problema paragonabile al problema del deadlock.

notify()si sveglia un thread mentre notifyAll()si sveglia tutto. Per quanto ne so non c'è via di mezzo. Ma se non sei sicuro di cosa notify()farà ai tuoi thread, usa notifyAll(). Funziona come un fascino ogni volta.

Tutte le risposte di cui sopra sono corrette, per quanto posso dire, quindi ti dirò qualcos'altro. Per il codice di produzione dovresti davvero usare le classi in java.util.concurrent. C'è molto poco che non possano fare per te, nell'area della concorrenza in Java.

notify() ti permette di scrivere codice più efficiente di notifyAll() .

Considera il seguente pezzo di codice eseguito da più thread paralleli:

synchronized(this) {
    while(busy) // a loop is necessary here
        wait();
    busy = true;
}
...
synchronized(this) {
    busy = false;
    notifyAll();
}

Può essere reso più efficiente usando notify():

synchronized(this) {
    if(busy)   // replaced the loop with a condition which is evaluated only once
        wait();
    busy = true;
}
...
synchronized(this) {
    busy = false;
    notify();
}

Nel caso in cui si disponga di un numero elevato di thread o se la condizione del ciclo di attesa è costosa da valutare, notify()sarà significativamente più veloce di notifyAll(). Ad esempio, se si dispone di 1000 thread, 999 thread verranno risvegliati e valutati dopo il primo notifyAll(), quindi 998, quindi 997 e così via. Al contrario, con la notify()soluzione, verrà risvegliato un solo thread.

Utilizzare notifyAll()quando è necessario scegliere quale thread eseguirà il lavoro successivo:

synchronized(this) {
    while(idx != last+1)  // wait until it's my turn
        wait();
}
...
synchronized(this) {
    last = idx;
    notifyAll();
}

Infine, è importante capire che in caso di notifyAll(), il codice all'interno dei synchronizedblocchi che sono stati risvegliati verrà eseguito in sequenza, non tutti in una volta. Diciamo che ci sono tre thread in attesa nell'esempio sopra e il quarto thread chiama notifyAll(). Tutti e tre i thread verranno risvegliati ma solo uno inizierà l'esecuzione e verificherà le condizioni del whileloop. Se la condizione è true, chiamerà di wait()nuovo, e solo allora il secondo thread inizierà l'esecuzione e controllerà la sua whilecondizione di loop, e così via.

Ecco una spiegazione più semplice:

Hai ragione nel dire che, sia che usi notification () o notifyAll (), il risultato immediato è che esattamente un altro thread acquisirà il monitor e inizierà l'esecuzione. (Supponendo che alcuni thread siano stati effettivamente bloccati su wait () per questo oggetto, altri thread non correlati non stanno assorbendo tutti i core disponibili, ecc.) L'impatto viene dopo.

Supponiamo che il thread A, B e C attendessero questo oggetto e che il thread A ottenga il monitor. La differenza sta in ciò che accade quando A rilascia il monitor. Se hai utilizzato Notify (), allora B e C sono ancora bloccati in wait (): non stanno aspettando sul monitor, stanno aspettando di essere avvisati. Quando A rilascia il monitor, B e C rimarranno comunque lì, in attesa di una notifica ().

Se hai utilizzato notificationAll (), allora B e C hanno entrambi superato lo stato di "wait for notification" e sono entrambi in attesa di acquisire il monitor. Quando A rilascia il monitor, B o C lo acquisiranno (supponendo che nessun altro thread sia in competizione per quel monitor) e inizieranno l'esecuzione.

Questa risposta è una riscrittura grafica e una semplificazione dell'eccellente risposta di xagyg , inclusi i commenti di Eran .

Perché usare NotifyAll, anche quando ogni prodotto è destinato a un singolo consumatore?

Considera produttori e consumatori, semplificati come segue.

Produttore:

while (!empty) {
   wait() // on full
}
put()
notify()

Consumatore:

while (empty) {
   wait() // on empty
}
take()
notify()

Si supponga che 2 produttori e 2 consumatori condividano un buffer di dimensioni 1. L'immagine seguente mostra uno scenario che porta a un deadlock , che sarebbe evitato se tutti i thread utilizzati venissero avvisati .

Ogni notifica è etichettata con il thread in fase di riattivazione.

Vorrei menzionare ciò che è spiegato in Java Concurrency in Practice:

Primo punto, sia Notifica o Notifica tutto?

It will be NotifyAll, and reason is that it will save from signall hijacking.

Se due thread A e B sono in attesa su predicati di condizioni diverse della stessa coda di condizioni e viene richiamata la notifica, dipende da JVM a quale thread JVM notificherà.

Ora, se la notifica era pensata per il thread A e JVM notificati, il thread B si risveglierà e vedrà che questa notifica non è utile, quindi attenderà nuovamente. E il thread A non verrà mai a conoscenza di questo segnale perso e qualcuno ha dirottato la sua notifica.

Quindi, chiamare notificationAll risolverà questo problema, ma avrà di nuovo un impatto sulle prestazioni poiché notificherà tutti i thread e tutti i thread competeranno per lo stesso blocco e comporterà il cambio di contesto e quindi il caricamento sulla CPU. Ma dovremmo preoccuparci delle prestazioni solo se si sta comportando correttamente, se il comportamento in sé non è corretto, le prestazioni sono inutili.

Questo problema può essere risolto utilizzando l'oggetto Condizione del blocco esplicito del blocco, fornito in jdk 5, in quanto fornisce un'attesa diversa per ogni predicato della condizione. Qui si comporterà correttamente e non ci saranno problemi di prestazioni in quanto chiamerà il segnale e si assicurerà che solo un thread sia in attesa di quella condizione

notify()- Seleziona un thread casuale dal set di attesa dell'oggetto e lo mette nello BLOCKEDstato. Il resto dei thread nel set di attesa dell'oggetto è ancora nello WAITINGstato.

notifyAll()- Sposta tutti i thread dal set di attesa dell'oggetto sullo BLOCKEDstato. Dopo aver usato notifyAll(), non ci sono thread rimanenti nel set di attesa dell'oggetto condiviso perché tutti sono ora nello BLOCKEDstato e non nello WAITINGstato.

BLOCKED- bloccato per acquisizione blocco. WAITING- in attesa di notifica (o bloccato per il completamento del join).

Tratto dal blog su Java efficace:

The notifyAll method should generally be used in preference to notify. 

If notify is used, great care must be taken to ensure liveness.

Quindi, quello che ho capito è (dal blog di cui sopra, commento di "Yann TM" sulla risposta accettata e sui documenti Java ):

• notify (): JVM risveglia uno dei thread in attesa su questo oggetto. La selezione del filo è fatta arbitrariamente senza equità. Quindi lo stesso thread può essere risvegliato ancora e ancora. Quindi lo stato del sistema cambia ma non si fanno progressi reali. Creando così un livelock .
• notifyAll (): JVM risveglia tutti i thread e quindi tutti i thread corrono per il blocco su questo oggetto. Ora, lo scheduler della CPU seleziona un thread che acquisisce il blocco su questo oggetto. Questo processo di selezione sarebbe molto meglio della selezione di JVM. Quindi, garantendo vivacità.

Dai un'occhiata al codice pubblicato da @xagyg.

Supponiamo che due thread diversi stiano aspettando due condizioni diverse:
il primo thread è in attesa buf.size() != MAX_SIZEe il secondo thread è in attesa buf.size() != 0.

Supponiamo che ad un certo punto buf.size() non sia uguale a 0 . JVM chiama notify()invece di notifyAll()e viene notificato il primo thread (non il secondo).

Il primo thread viene svegliato, verifica per buf.size()quale potrebbe tornare MAX_SIZEe torna in attesa. Il secondo thread non viene svegliato, continua ad attendere e non chiama get().

notify() sveglia il primo thread che ha chiamato wait() lo stesso oggetto.

notifyAll()riattiva tutti i thread che hanno richiamato wait()lo stesso oggetto.

Il thread con priorità più alta verrà eseguito per primo.

notifica notificherà solo un thread in stato di attesa, mentre notifica a tutti notificherà tutti i thread nello stato di attesa ora tutti i thread notificati e tutti i thread bloccati sono idonei per il blocco, fuori dal quale solo uno riceverà il blocco e tutti gli altri (compresi quelli che sono in stato di attesa prima) saranno in stato bloccato.

Riassumendo le eccellenti spiegazioni dettagliate sopra, e nel modo più semplice che mi viene in mente, ciò è dovuto alle limitazioni del monitor integrato JVM, che 1) viene acquisito sull'intera unità di sincronizzazione (blocco o oggetto) e 2) non discrimina la condizione specifica in attesa / notificata / circa.

Ciò significa che se vengono utilizzati più thread in attesa in condizioni diverse e viene utilizzato notification (), il thread selezionato potrebbe non essere quello che farebbe progressi sulla condizione appena soddisfatta, causando quel thread (e altri thread attualmente ancora in attesa che sarebbero in grado per soddisfare la condizione, ecc.) di non essere in grado di fare progressi, e infine la fame o il blocco del programma.

Al contrario, notifyAll () consente a tutti i thread in attesa di riacquistare il blocco e verificare le rispettive condizioni, consentendo in tal modo di compiere progressi.

Quindi Notify () può essere utilizzato in modo sicuro solo se è garantito un thread in attesa per consentire di fare progressi nel caso in cui venga selezionato, il che in generale è soddisfatto quando tutti i thread all'interno dello stesso monitor controllano solo la stessa condizione - una condizione abbastanza rara caso in applicazioni del mondo reale.

Quando si chiama wait () dell '"oggetto" (aspettandosi che venga acquisito il blocco dell'oggetto), intern questo rilascerà il blocco su quell'oggetto e aiuterà gli altri thread ad avere il blocco su questo "oggetto", in questo scenario ci sarà più di 1 thread in attesa di "risorsa / oggetto" (considerando che anche gli altri thread hanno emesso l'attesa sullo stesso oggetto sopra e lungo la strada ci sarà un thread che riempie la risorsa / oggetto e invoca notification / notificationAll).

Qui quando si emette la notifica dello stesso oggetto (dallo stesso / altro lato del processo / codice), questo rilascerà un singolo thread bloccato e in attesa (non tutti i thread in attesa - questo thread rilasciato verrà scelto da JVM Thread Scheduler e tutto il processo di acquisizione dei blocchi sull'oggetto è uguale al normale).

Se hai solo un thread che condividerà / funzionerà su questo oggetto, è ok usare il metodo notify () da solo nella tua implementazione wait-notification.

se ti trovi in ​​una situazione in cui più di un thread legge e scrive su risorse / oggetti in base alla tua logica aziendale, allora dovresti andare per notificationAll ()

ora sto guardando come esattamente jvm sta identificando e rompendo il thread di attesa quando emettiamo notification () su un oggetto ...

Mentre ci sono alcune risposte solide sopra, sono sorpreso dal numero di confusioni e incomprensioni che ho letto. Questo probabilmente dimostra l'idea che si dovrebbe usare java.util.concurrent il più possibile invece di provare a scrivere il proprio codice concorrente rotto. Torna alla domanda: per riassumere, la migliore pratica oggi è EVITARE di avvisare () in TUTTE le situazioni a causa del problema di sveglia perso. Chiunque non lo capisca non dovrebbe essere autorizzato a scrivere un codice di concorrenza mission-critical. Se sei preoccupato per il problema della pastorizia, un modo sicuro per svegliare un thread alla volta è: 1. Costruire una coda di attesa esplicita per i thread in attesa; 2. Far attendere a ciascuno dei thread nella coda il suo predecessore; 3. Al termine, ogni chiamata di thread deve essere avvisata (). Oppure puoi usare Java.util.concurrent. *,

Svegliarsi tutto qui non ha molto significato. attendi notifica e notifica, tutti questi vengono inseriti dopo aver posseduto il monitor dell'oggetto. Se un thread è in fase di attesa e viene chiamato un messaggio di notifica, questo thread occuperà il blocco e nessun altro thread in quel punto potrà occuparlo. Quindi l'accesso simultaneo non può aver luogo affatto. Per quanto ne so, qualsiasi chiamata ad attendere di notifica e notifica può essere effettuata solo dopo aver preso il blocco sull'oggetto. Correggimi se sbaglio.