Java ArrayList スレッドセーフ removeメソッド

Question

JavaのArrayLIstのスレッドセーフについて質問です。

Java SIlver 黒本より

ソース１

Arraylist<String> list = new ArrayList<>();

list.add("A");
list.add("B");
list.add("C");

for (String str : list){

    if("B".equals(str)){
        list.remove(str);
}else{
System.out.println(str);
}   

}

ソース２

Arraylist<String> list = new ArrayList<>();

list.add("A");
list.add("B");
list.add("C");
list.add("D");
list.add("E");

for (String str : list){

    if("C".equals(str)){
        list.remove(str);
}

}

for (String str : list){
System.out.println(str);
}

＊クラスの宣言とmainメソッドは省略しました。

---

このソース1の実行した結果として
A
が出力。

---

ソース2は実行時に例外がスローされるとあります。
ConcurrentModificationException←これ

その理由として、ループで読みだしている最中にremoveメソッドを呼び出しているからとあります。
しかし、ソース1でもremoveメソッドを呼び出しているのにソース1では例外がスローされません。これはなぜでしょうか？

私なりの考察。

ソース1では拡張for文2回目のループでremoveメソッドが処理され3買い目のループは要素がなくなり2回目で終わり、残りの要素に影響されない。

ソース2では拡張for文3回目のループでremoveメソッドが処理され4回目ループの際の"E"がまだ残っているため要素数の順番に影響があるから？

---

よろしくお願いします。

Answer 1

大まかに言うと考察はあってます。
要素数の順番ではなく、ループ中に要素数が変わることでエラーになります。

またソース１を実行した際も、
直感的にはAとCが出力されることが期待値になると思うのでエラーですよね。

ということで、普通ループ中に要素追加削除をするのはNGになっています。

stacktraceとclassファイル見ると多少詳しくと思うんですが、

java.util.ConcurrentModificationException
	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
	at java.util.ArrayList$Itr.next(ArrayList.java:851)

Iterator arg2 = e.iterator();
while(arg2.hasNext()) {
   String str = (String)arg2.next();
   if("B".equals(str)) {
      e.remove(str);
   } else {
      System.out.println(str);
   }
}

ArrayList$Itr.checkForComodificationで要素数のチェック・エラー判定を行っているので、
ソース１の場合はremoveした後に次のhasNextでループを抜けるため、
nextが呼ばれずエラーになりません。

Answer 2

他の方の回答に似てますが微妙に違うコメントをしてみます。

ConcurrentModificationException(長いので以下CMEとよびます)が発生する・しないことの厳密な意味を理解しておくことは重要だと思います。

以下ArrayListのリファレンス：

通常、非同期の並行変更がある場合、確かな保証を行うことは不可能なので、イテレータのフェイルファストの動作を保証することはできません。フェイルファスト・イテレータは、ベスト・エフォート・ベースでConcurrentModificationExceptionをスローします。したがって、正確を期すためにこの例外に依存するプログラムを書くことは誤りです。イテレータのフェイルファストの動作はバグを検出するためにのみ使用すべきです。

つまりArrayListは多重処理による処理間違いを確実に検出することは狙っておらず、性能を劣化させない程度の手間をかけることで「うまくいけば例外を発することができることがある」となっているわけです。このためCMEが発生すれば「バグであることは明らか」ですが、CMEが発生しなかった場合は正しいかといえばその保証はないということになってしまいます。

コレクションに限らず一般にオブジェクトの状態を変更するスレッドが複数存在するなら**一貫性を保つに必要な処理範囲は他スレッドからの操作をガードする(排他する)**ことが必要です。ゆえにご質問のような処理をするなら例えば以下のようにしなければならない場合も多いでしょう。

synchronized (同期用オブジェクト) {
  for (String str : list){
    if("C".equals(str)){
      list.remove(str);
  }
}

---

補足：masaya_ohashiさんが挙げておられるIterator#removeは、こと多重処理についてはList#removeに比べ「より安全であるとはいえない」と思います。

masaya_ohashiさんご自身もIterator#removeが安全とは限らない点を「イテレータを自分で用意して、イテレータのremoveを使いましょう。 」という表現に込められているのだと思いました。ただ、読み手によっては「Iterator#removeを使えば安全なのかな？」とハヤトチリする可能性もあると思います。また実はそのような特別なIteratorを自分で定義するのは手間がかかる上に「それなりに処理コストがかかる」ものになるでしょう。ちなみにCollections.synchronizedListで同期リストを作ったとしてもそのiterator()メソッドで返されるイテレーターはhasNext(), next(), remove()などの操作を行う場合に利用者自身が(synchronized文を使って)同期した上で使わないといけないことにも注意すべきでしょう。こうしたことから、

複数のスレッドで同一のコレクションを並行して走査（かつ構造変更）をするというのは実現は可能ですが、個人的には余程の理由がない限りそういうことは避けて、走査処理全体をガードした方が簡単確実であることが多い気がします。

Answer 3

ConcurrentModificationExceptionが発生するかしないかは「時の運」がからんでいます。監視のタイミングの気まぐれによって起こるといっても過言ではありません。ちなみに、ソース1もソース2も、どちらも「スレッドセーフでないListの、イテレータ操作中のremove」という点においてConcurrentModificationExceptionが発生する可能性をはらんでいます。

Listからイテレータ操作中に安全に要素をremoveする場合、このような書き方が正しいです。

Iterator<String> itr = list.iterator();
while(itr.hasNext()){
    str = itr.next();
    if("C".equals(str)){
        itr.remove();
    }
}

拡張for文において、「ConcurrentModificationExceptionの起こらない安全なremove方法」は存在しません。イテレータを自分で用意して、イテレータのremoveを使いましょう。

#追記
存在しないとは言いましたが、Collections.synchronizedListを使えば拡張for内で安全にremove可能な同期Listに置き換えることができます。ただし、あまり理解せずにこれに頼るのはよくないです。速度も遅くなりますし、デッドロックの発生の危険性もあります。
http://qiita.com/mountcedar/items/3a4d147d12e8b38cf6d0

Answer 4

過去に全く同じ質問が複数回投稿されているので一応貼っておきますね

ConcurrentModificationExceptionが発生するパターンについて
拡張for文の動作がわかりません。
ConcurrentModificationExceptionの出現タイミングについて