Ce este Thread-Safe BlockingQueue în Java? Când ar trebui să-l folosești? Implementare atașată

Publicat: 2021-04-30
Ce este Threadsafe BlockingQueue în Java și când ar trebui să-l utilizați

Până acum am scris două articole despre conceptul Producer Consumer pe Crunchify. Primul pentru a explica Java Semaphore și Mutex și al doilea pentru a explica Concurrent Read/Write.

În acest tutorial Java vom trece peste același concept de producător/consumator pentru a explica BlockingQueue in Java .

Care sunt avantajele Blocking Queue în Java?

Un java.util.Queue acceptă operațiuni care așteaptă ca coada să nu devină goală la preluarea unui element și așteaptă ca spațiu să devină disponibil în coadă atunci când stochează un element.

java.util.BlockingQueue în java - Crunchify

Trebuie să creăm patru clase Java:

  1. CrunchifyMessage.java pentru a pune și a primi mesaj
  2. CrunchifyBlockingProducer.java pentru a pune mesajul în coadă
  3. CrunchifyBlockingConsumer.java pentru a primi mesajul din coadă
  4. CrunchifyBlockingMain.java pentru a începe testul

Implementările BlockingQueue sunt thread-safe . Toate metodele de așteptare sunt de natură atomică și folosesc blocări interne.

Să începem cu implementarea Thread-Safe BlockingQueue în Java

Pasul 1

Creați clasa CrunchifyMessage.java . Acesta este un simplu obiect Java.

Pasul 2

Creați producătorul CrunchifyBlockingProducer.java care a creat mesaje simple și a pus-o în coadă.

Pasul 3

Creați clasa CrunchifyBlockingConsumer.java care consumă mesajul din coadă.

Pasul-4

Creați metoda simplă CrunchifyBlockingMain.java care rulează testul BlockingQueue. Rulați acest program pentru a verifica comportamentul BlockingQueue.

Un BlockingQueue nu acceptă elemente nule . Implementările aruncă NullPointerException la încercările de a adăuga , pune sau oferi un null .

O valoare nulă este folosită ca valoare sentinelă pentru a indica eșecul operațiunilor de sondare .

Rezultat:

Când ar trebui să folosim java.util.concurrent.BlockingQueue?

  • Când doriți să reduceți un fel de solicitare primită, ar trebui să utilizați același lucru
  • Un producător poate ajunge cu mult înaintea consumatorilor cu o coadă nelimitată. Dacă consumatorul nu ajunge din urmă cu producătorul, atunci poate provoca o OutOfMemoryError . În situații ca acestea, poate fi mai bine să semnalați unui potențial producător că coada este plină și să renunțe rapid la un eșec.
    • Cu alte cuvinte: producătorii sunt în mod firesc throttled.
  • Coada de blocare este utilizată în mod normal în aplicațiile concurente
  • Oferă o implementare corectă, sigură pentru fire
  • Consumul de memorie ar trebui, de asemenea, limitat