変更することは一般に許可されない。通常、そのような環境では、繰り返し処理の結果は保証されない。いくつかの反復子(Iterator)の実装(JREが提供するすべての一般的な目的のコレクションの実装の、反復子の実装を含む)は、その動作が検出された場合にこの例外をスローすることを選択できる。この例外をスローする反復子は「フェイルファスト」反復子と呼ばれる。「フェイルファスト」反復子は、将来の予測できない時点において予測できない動作が発生する危険を回避するために、ただちにかつ手際よく例外をスローする。通常、非同期の並行変更がある場合、確かな保証を行うことは不可能なので、フェイルファストの動作を保証することはできない。反復処理を正確に行うために、この例外に依存するプログラムを書くことは誤りである。バグを検出するためにのみ使用すること。依存するのは不適切である。フェイルファスト動作が要素をいくつ処理してから発生するかは決まっていない。コレクションに変更カウントを設ける方式で実装されている。このチェックは同期されていないので、変更カウントの値は最新のものではないかもしれず、そうするとイテレータは変更が行われたことが分からないかもしれない。これは並行変更を検出するコードが実行性能に与える影響を抑えるための、意図的な設計トレードオフである。イディオム)は内部でイテレータを使っていることに注意。ループも並行変更の問題の影響を受ける可能性がある。そのため、未定義の動作となる。イテレータが最後に返した要素を削除する。その動作は完全に規定されており、コレクションに対する反復処理中に使っても安全である。(マルチスレッド)以下の違反コード例は、シングルスレッドの場合には問題ないが、マルチスレッドの場合にはセキュアではない。変更できるからである。メソッドがコレクションに変更を加える可能性もある。同期コレクションでラップし、すべての変更操作を同一のロックの管理下に置いている。対して反復処理を行う前に深いコピーを作成している。}}リストの深いコピーを作成すれば、コピー元のリストに変更操作が行われても反復処理は影響を受けない。このアプローチは他のテクニックよりも高くつくことが多い。古くなったデータを処理している危険もあるため、コードが正しい動作をしなくなるかもしれない。その変更操作を、基となる配列の新しいコピーをつくる形で実装している。このデータ構造は完全にスレッドセーフであり、変更操作よりもデータ構造を辿る操作のほうが多い状況に最適化されている。ループが開始された)時点の状態のデータ構造を辿ることになる。それ以降に行われた変更は、データ構造を辿っているときには見えない。そのため、変更操作が頻繁に行わる場合や、変更操作の結果が、辿っている最中のデータ構造に反映されるべき場合には、この手法は不適切である。}}リスク評価コレクションに対する反復処理中に変更を行うと、未定義の動作となる。ツールのなかには、基になるコンテナが変更された後にイテレータが使われるケースを検出できるものもある。破壊される問題である。ConcurrentModificationException翻訳元これは以下のページを翻訳したものです。有このページは役に立ちましたか?javascriptを有効にすると、ご回答いただけます。その他のご意見はPCサイトにて入力願います。