ParseObject.collectFetchedObjects（）はConcurrentModificationExceptionをスローします

Question

私はParseを使用していますが、私はこの例外を時折ランダムに取得します。問題は、これが起こる原因を知りませんか？ "ParseObject.collectFetchedObjects（）"の呼び出しをトリガーするものは誰でも知っていますか？ ConcurrentModificationExceptionの原因は何でしょうか？ここ は、スタックトレースの重要な部分である：

java.util.ConcurrentModificationException 
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:806) 
at java.util.HashMap$ValueIterator.next(HashMap.java:838) 
at com.parse.ParseTraverser.traverseInternal(ParseTraverser.java:87) 
at com.parse.ParseTraverser.traverse(ParseTraverser.java:137) 
at com.parse.ParseObject.collectFetchedObjects(ParseObject.java:817) 
at com.parse.ParseObject.access$700(ParseObject.java:49) 
at com.parse.ParseObject$13.then(ParseObject.java:1487) 
at com.parse.ParseObject$13.then(ParseObject.java:1484) 
at bolts.Task$15.run(Task.java:917) 
at bolts.BoltsExecutors$ImmediateExecutor.execute(BoltsExecutors.java:105) 
at bolts.Task.completeAfterTask(Task.java:908) 
at bolts.Task.continueWithTask(Task.java:715) 

Answer 1

"ParseObject.collectFetchedObjects()" 

この例外は、そのような変更が許可されていない場合、オブジェクトの同時変更を検出したメソッドによってスローされる可能性があります。

例えば、あるスレッドがCollectionを変更するのは一般的に許可されていませんが、別のスレッドがそのスレッドを反復処理している間は許可されません。一般に、これらの状況では、反復の結果は未定義です。この動作が検出された場合、Iterator実装（JREによって提供されるすべての汎用コレクション実装の実装を含む）によっては、この例外がスローされる可能性があります。これを行うイテレータは、フェイル・ファースト・イテレータとして知られています。これらのイテレータは、将来不確定な時間に任意の非決定論的な動作を実行するリスクを回避するため、迅速かつきれいに機能しません。

この例外は、オブジェクトが別のスレッドによって同時に変更されたことを示すとは限りません。 1つのスレッドがオブジェクトの契約に違反する一連のメソッド呼び出しを発行すると、オブジェクトはこの例外をスローする可能性があります。たとえば、スレッドがフェイル・ファースト・イテレータを使用してコレクションを反復している間に、スレッドがコレクションを直接変更した場合、イテレータはこの例外をスローします。

一般的に言えば、非同期の同時変更がある場合には、ハード保証ができないため、フェイル・ファーストの動作は保証されません。フェイル・ファースト・オペレーションは、ベスト・エフォート・ベースでConcurrentModificationExceptionをスローします。したがって、この例外に依存するプログラムを記述するのは間違いです。ConcurrentModificationExceptionは、バグを検出するためにのみ使用してください。

文書から

実行スレッド数を確認して同期してください。