Différence entre BlockingQueue et TransferQueue

De TransferQueue Javadoc:

Un BlockingQueue dans lequel les producteurs peuvent s'attendre pour les consommateurs de recevoir des éléments. Un TransferQueue peut être utile par exemple dans la transmission de message d'applications dans lesquelles les producteurs, parfois, l'aide de la méthode de transfert(E)) attendre la réception des éléments par les consommateurs en invoquant prendre ou de sondage, alors qu'à d'autres moments de mise en file d'éléments (par l'intermédiaire de méthodes de vente), sans attendre la réception.

En d'autres termes, lorsque vous utilisez BlockingQueue, vous ne pouvez mettre de l'élément dans la file d'attente (et de la bloquer en cas de file d'attente est pleine). Avec TransferQueue, vous pouvez bloquer jusqu'à ce que d'autres thread reçoit votre élément (vous devez utiliser les nouvelles transfer méthode). C'est la différence. Avec BlockingQueue, vous ne pouvez pas attendre jusqu'à ce que d'autres thread supprime votre élément (uniquement lorsque vous utilisez SynchronousQueue, mais qui n'est pas vraiment une file d'attente).

Autre que cela, TransferQueue est aussi un BlockingQueue. Découvrez de nouvelles méthodes disponibles dans les TransferQueue: http://download.oracle.com/javase/7/docs/api/java/util/concurrent/TransferQueue.html (transfert, tryTransfer, hasWaitingConsumer, getWaitingConsumerCount).

---

Collections Cadre des Améliorations dans Java SE 7 dit explicitement:

L'interface TransferQueue a été ajouté. C'est un raffinement de l'interface BlockingQueue dans lequel les producteurs peuvent attendre pour les consommateurs de recevoir des éléments. Une mise en œuvre de la nouvelle interface est également inclus dans cette version, LinkedTransferQueue.

Une question il y a longtemps et @la réponse de Pierre est vraiment complexe. Pour les personnes qui veulent savoir comment TransferQueue fonctionne dans la pratique, peut-être que vous pouvez vous référer à la démo ci-dessous.

import java.util.concurrent.LinkedTransferQueue;
import java.util.concurrent.TransferQueue;
public class TransferQueueExample {
TransferQueue<String> queue = new LinkedTransferQueue<String>();
class Producer implements Runnable{
@Override
public void run() {
//TODO Auto-generated method stub
for(int i = 0; i < 2; i++){
try{
System.out.println("Producer waiting to transfer: " + i);
queue.transfer("" + i);
System.out.println("Producer transfered: " + i);
}catch(Exception e){
e.printStackTrace();
}
}
}
}
class Consumer implements Runnable{
@Override
public void run() {
//TODO Auto-generated method stub
for(int i = 0; i < 2; i++){
try{
Thread.sleep(2000);
System.out.println("Consumer waiting to comsume: " + i);
queue.take();
System.out.println("Consumer consumed: " + i);
}catch(Exception e){
e.printStackTrace();
}
}
}
}
public static void main(String args[]){
TransferQueueExample example = new TransferQueueExample();
new Thread(example.new Producer()).start();
new Thread(example.new Consumer()).start();
}
}

La sortie est:

Producer waiting to transfer: 0
Consumer waiting to comsume: 0
Consumer consumed: 0
Producer transfered: 0
Producer waiting to transfer: 1
Consumer waiting to comsume: 1
Consumer consumed: 1
Producer transfered: 1

La transfer est là que la différence se passe.

Transferts de l'élément à un consommateur, en attente si nécessaire.

Plus précisément, les transferts de l'élément spécifié immédiatement si il y
il existe un consommateur déjà en attente pour le recevoir (à prendre ou temporisée
sondage), d'autre attend jusqu'à ce que l'élément est reçu par un consommateur.

Que la javadoc, le transfer va attendre jusqu'à ce que le consommateur a pris le produit à l'écart.

C'est la raison pour laquelle "Producer waiting to transfer: 0" est appelé tout d'abord, et après environ 2 secondes, après qu'il a été reçu par le consommateur, le Producer transfered: 0 est appelé ensuite.