Spliterator: Thread-Safe oder nicht?

Question

Suche in der Dokumentation des Spliterator und nach ihm, die Spliterator nicht Thread-sicher ist:

Trotz ihrer offensichtlichen Nutzen in parallelen Algorithmen sind spliterators nicht als Thread-sicher zu erwarten; stattdessen sollten Implementierungen paralleler Algorithmen unter Verwendung von Spliteratoren sicherstellen, dass der Spliterator nur von jeweils einem Thread gleichzeitig verwendet wird. Dies ist im Allgemeinen leicht durch serielle Thread-Beschränkung zu erreichen, was oft eine natürliche Folge von typischen parallelen Algorithmen ist, die durch rekursive Dekomposition arbeiten.

Aber in der weiteren Dokumentation, die eine widersprüchliche Aussage die obigen Aussage heißt es:

Struktur Interferenz einer Quelle kann auf folgende Weise (in ungefährer Reihenfolge abnehmender Erwünscht) verwaltet werden:

Die Quelle verwaltet gleichzeitige Änderungen. Zum Beispiel ist ein Schlüsselsatz einer java.util.concurrent.ConcurrentHashMap eine gleichzeitige Quelle. Ein aus der Quelle erstellter Splitterator meldet ein Merkmal von CONCURRENT.

Also bedeutet das, dass ein Spliterator, der aus einer Thread-sicheren Sammlung generiert wurde, Thread-sicher ist? Ist es richtig?

Answer 1

Nein, ein Spliterator die Berichterstattung über die CONCURRENT Merkmal wird einen Thread sicher Quelle haben, was bedeutet, dass es sicher auch darüber laufen kann, wenn die Quelle gleichzeitig geändert wird. Aber die Spliterator selbst kann noch einen Zustand haben, der nicht gleichzeitig manipuliert werden darf.

Beachten Sie, dass Ihr Zitat aus einer Beschreibung stammt, wie "strukturelle Interferenzen einer Quelle gemanagt werden können", und nicht auf das Verhalten des Spliterators im Allgemeinen.

Dies ist auch an den documentation of the CONCURRENT characteristic itself bereitgestellt:

Kennwert bedeutet, daß die Elementquelle (so dass Hinzufügungen, Ersetzungen und/oder Entfernungen) durch mehrere Threads ohne externe Synchronisation sicher gleichzeitig modifiziert werden. Wenn dies der Fall ist, erwartet der Spliterator eine dokumentierte Richtlinie bezüglich der Auswirkungen von Änderungen während des Traversierens.

Nichts anderes.

Also die Folgen dieser Eigenschaften sind erstaunlich klein. Eine Spliterator Berichterstattung entweder CONCURRENT oder IMMUTABLE wird nie werfen ConcurrentModificationException, das ist alles. In allen anderen Punkten werden die Unterschiede zwischen diesen Merkmalen nicht von der API Stream erkannt, da die API niemals Quellenmanipulationen durchführt, tatsächlich kennt sie die Quelle nicht (anders als indirekt über die Spliterator), also es konnte weder solche Manipulationen durchführen noch erkennen, ob eine gleichzeitige Änderung stattgefunden hat.