Trådsikkerhed ved BlockingQueues drainTo () -metode

Dokumentation af BlockingQueue siger, at bulkoperationer ikke er trådsikre, selvom den ikke udtrykkeligt nævner metoden drainTo ().

BlockingQueue-implementeringer er trådsikker. Alle kømetoder opnå deres virkninger atomisk ved hjælp af interne låse eller andre former for samtidighedskontrol. Men størstedelen Indsamlingshandlinger addAll, containAll, retainAll og removeAll udføres ikke nødvendigvis atomisk, medmindre andet er angivet i en implementering. Sådan er det muligt, for eksempel for addAll (c) at mislykkes (kaster en undtagelse) efter kun at tilføje nogle af elementerne i c.

Dokumentation af metoden drainTo () angiver, at samlingen, hvortil elementerne i BlockingQueue drænes, ikke kan ændres på trådsikker måde. Men det nævner ikke noget om, at drainTo () er trådsikker.

Fjerner alle tilgængelige elementer fra denne kø og føjer dem til det givne kollektion. Denne handling kan være mere effektiv end gentagne gange at afstemme dette kø. En fejl opstået under forsøger at tilføje elementer til samling c kan resultere i elementer være i hverken, den ene eller begge samlinger når den tilknyttede undtagelse kastes. Forsøg på at dræne en kø til sig selv resulterer i IllegalArgumentException. Yderligere, den opførsel af denne operation er udefineret, hvis den specificerede samling ændres, mens operationen er i

Så er metoden drainTo () trådsikker? Med andre ord, hvis en tråd har påkaldt drainTo () -metoden på en blokerende kø, og den anden kalder add () eller put () i den samme kø, er køens tilstand konsistent i slutningen af ​​begge operationer?