BlockingQueue et putAll

Question

Quelqu'un sait-il pourquoi la BlockingQueue de Java n'a pas de méthode putAll ? Y a-t-il un problème avec une telle méthode ? Y a-t-il de bonnes façons de contourner ce problème sans avoir à réimplémenter complètement BlockingQueue ?

Answer 1

for (Item item : items) {
    queue.put(item);
}

3 lignes, pas sûr qu'il s'agisse d'une réimplémentation complète de la file d'attente bloquante.

J'imagine qu'il veut que vous mettiez 1 par 1 au cas où des fils attendent de les lire, ils n'attendent pas que vous ayez fini de les lire tous.

Answer 2

J'ai rencontré le même problème avec ArrayBlockingQueue . Nous voulions des méthodes supplémentaires qui manquaient :

• void putAll(Collection<? extends E> c) throws InterruptedException
• int drainAtLeastOneTo(@OutputParam Collection<? super E> c) throws InterruptedException
• int drainAtLeastOneTo(@OutputParam Collection<? super E> c, int maxElements) throws InterruptedException

Certaines personnes préconisent d'utiliser BlockingQueue<List<E>> mais cela nécessite l'utilisation de listes de mallocs. Il est parfois préférable de l'éviter. De plus, cela suppose que le producteur et le consommateur utilisent les mêmes tailles de "morceaux".

En ce qui concerne la vidange : Là encore, il peut être souhaitable d'avoir un décalage entre la taille des morceaux du producteur et celle du consommateur. Ainsi, le producteur peut insérer des éléments individuels, alors que le consommateur travaille sur des lots. drainTo() ne bloque pas, donc drainAtLeastOneTo() était une solution.

En fin de compte, nous avons copié l'impl par défaut de ArrayBlockingQueue et a ajouté les méthodes directement. Là encore, l'inconvénient est qu'il faut opérer sur un type concret, au lieu d'une interface BlockingQueue .

Vous pouvez également envisager d'utiliser le célèbre (infâme ?) LMAX Disruptor mais le modèle est très différent de celui d'un BlockingQueue car vous ne contrôlez pas le moment où les articles sont consommés.