Spliterator：スレッドセーフかどうか私はSpliteratorの文書の中に探していますし、それに応じて、Spliteratorはスレッドセーフではありません

Question

：

並列アルゴリズムにおける彼らの明白な有用性にもかかわらず、spliteratorsは、スレッドセーフであることが予想されていません。その代わりに、スプライテータを使用する並列アルゴリズムの実装は、スプライテータが一度に1つのスレッドのみによって確実に使用されるようにする必要があります。これは、一般的に、直列スレッド制限を介して達成することは容易であり、しばしば再帰的分解によって動作する典型的な並列アルゴリズムの自然な結果である。

しかし、上記の文に矛盾ステートメントを述べてそのさらなるドキュメントに：

源の構造的干渉は、（望ましさを減少させるのおおよその順序で）次の方法で管理することができます。

ソースは、同時変更を管理します。 たとえば、java.util.concurrent.ConcurrentHashMapのキーセットは、並行ソースです。ソースから作成されたSpliteratorは、CONCURRENTの特性を報告します。

これは、スレッドセーフなコレクションから生成されたSpliteratorはスレッドセーフであることを意味しますか？そうですか？

Answer 1

いいえ、CONCURRENT特性を報告Spliteratorは、ソースが同時に変更されます場合でも、安全にを反復処理できることを意味し、スレッドセーフソースを、持っています。しかし、Spliterator自体には、まだ同時に操作してはならない状態が残っている場合があります。

あなたの引用は、一般的なスプライテータの振る舞いではなく、「ソースの構造的干渉を管理する」方法の説明に由来することに注意してください。

これ

も documentation of the CONCURRENT characteristic itselfに設けられている。

特性値が外部同期せずに、複数のスレッドによって（追加、置換、および/または削除を可能にする）元素源が安全に同時に修正されてもよいことを意味します。その場合、Spliteratorは、トラバーサル中の変更の影響に関する文書化されたポリシーを持つことが期待されます。

他にはありません。

したがって、これらの特性の結果は驚異的です。 SpliteratorのいずれかがCONCURRENTまたはIMMUTABLEと報告された場合は、ConcurrentModificationExceptionを送信することはありません。他の点では、Stream APIはソース操作を全く実行しないため、これらの特性の違いはStream APIによって認識されません。実際にはソースは実際にはわかりません（間接的にはSpliterator以外）。そのような操作を行うことも、並行した変更が行われたかどうかを検出することもできませんでした。