In quali condizioni BlockingQueue.take genera un'eccezione interrotta?

Question

Supponiamo di avere un thread che consuma oggetti prodotti da un altro thread. Il suo metodo di esecuzione è il seguente, con INQUEUE essendo un BlockingQueue

boolean shutdown = false; 
while (!shutdown) { 
    try { 
     WorkItem w = inQueue.take(); 
     w.consume(); 
    } catch (InterruptedException e) { 
     shutdown = true; 
    } 
} 

Inoltre, un thread diverso segnalerà che non ci sono altri elementi di lavoro di interrompere il filo conduttore.() Genera un'eccezione interrotta se non ha bisogno di bloccare per recuperare il successivo oggetto di lavoro. Ad esempio, se il produttore segnala di aver completato la coda di lavoro, è possibile lasciare accidentalmente alcuni elementi in InQueue o saltare l'interruzione?

Answer 1

Un buon modo per segnalare la chiusura di una coda di blocco è di inviare un valore 'veleno' nella coda che indica che si è verificato un arresto. Ciò garantisce che il comportamento previsto della coda sia onorato. Chiamare Thread.interupt() non è probabilmente una buona idea se si vuole liberare la coda.

Per fornire qualche codice:

boolean shutdown = false; 
while (!shutdown) { 
    try { 
     WorkItem w = inQueue.take(); 
     if (w == QUEUE_IS_DEAD) 
      shutdown = true; 
     else 
      w.consume(); 
    } catch (InterruptedException e) { 
     // possibly submit QUEUE_IS_DEAD to the queue 
    } 
} 

Answer 2

Secondo javadoc, il metodo take() getteranno InterruptedException se interrotto durante l'attesa.

Answer 3

Il pacchetto java.concurrency.utils è stato progettato e implementato da alcune delle menti più raffinate nella programmazione simultanea. Inoltre, interrompere i thread come mezzo per terminarli viene esplicitamente approvato dal loro libro "Java Concurrency in Practice". Pertanto, sarei estremamente sorpreso se alcuni elementi fossero lasciati in coda a causa di un'interruzione.

Answer 4

Mi chiedevo la stessa cosa e leggendo la javadoc per take() Credevo che avrebbe gettato un'eccezione interrotta solo dopo aver preso tutti gli elementi in coda, poiché se la coda avesse degli elementi, non avrebbe dovuto "aspettare" ". ma ho fatto un piccolo test:

package se.fkykko.slask; 
import java.util.concurrent.ArrayBlockingQueue; 
import java.util.concurrent.BlockingQueue; 
import java.util.concurrent.atomic.AtomicLong; 

public class BlockingQueueTakeTest { 

public static void main(String[] args) throws Exception { 
    Runner t = new Runner(); 
    Thread t1 = new Thread(t); 
    for (int i = 0; i < 50; i++) { 
     t.queue.add(i); 
    } 
    System.out.println(("Number of items in queue: " + t.queue.size())); 
    t1.start(); 
    Thread.sleep(1000); 
    t1.interrupt(); 
    t1.join(); 
    System.out.println(("Number of items in queue: " + t.queue.size())); 
    System.out.println(("Joined t1. Finished")); 

} 

private static final class Runner implements Runnable { 
    BlockingQueue<Integer> queue = new ArrayBlockingQueue<Integer>(100); 
    AtomicLong m_count = new AtomicLong(0); 

    @Override 
    public void run() { 
     try { 
      while (true) { 
       queue.take(); 
       System.out.println("Took item " + m_count.incrementAndGet()); 
       final long start = System.currentTimeMillis(); 
       while ((System.currentTimeMillis() - start) < 100) { 
        Thread.yield(); //Spin wait 
       } 
      } 
     } 
     catch (InterruptedException ex) { 
      System.out.println("Interrupted. Count: " + m_count.get()); 
     } 
    } 
} 

} 

Il secondo classificato avrà 10-11 articoli e poi finire cioè prendere() getterà InterruptedException anche se c'è ancora elementi nella coda.

Riepilogo: utilizzare l'approccio Poison pill anziché, in tal caso, il pieno controllo su quanto rimane nella coda.