Почему Hashmap не работает быстро в функции изменения размера? (для проблемы с проблемой многопотоковой расы)

Question

Все, я пытался понять проблему с условием многопоточности для функции изменения размера Hashmap.

Как я читал из here. Проблема состояния гонки вызовет бесконечную связь цикла для списка записей.

Я уже знал, что Hashmap имеет механизм с быстрой задержкой, чтобы немедленно остановить доступ к нему несколькими потоками. Следующий код показывает это.

if (modCount != expectedModCount) 
       throw new ConcurrentModificationException(); 

Вопрос: почему сбойный режим не работает для функции изменения размера? код отлаживать ниже. (Jdk1.7)

void transfer(Entry[] newTable, boolean rehash) { 
     int newCapacity = newTable.length; 
     for (Entry<K,V> e : table) { 
      while(null != e) { 
       Entry<K,V> next = e.next; 
       if (rehash) { 
        e.hash = null == e.key ? 0 : hash(e.key); 
       } 
       int i = indexFor(e.hash, newCapacity); 
       e.next = newTable[i]; 
       newTable[i] = e; 
       e = next; 
      } 
     } 
    } 

Поскольку for не использует Iterator?

Обновлено

Или Поскольку размер функция не использует Put*, Remove*, Clear* метод, который будет вызывать значение modCount изменилось? Пожалуйста, помогите, пожалуйста, подтвердить это. (Простите меня плохой английский.)

Спасибо.

Answer 1

Javadoc of HashMap объясняет это: ConcurrentModificationException - лучшее усилие для обнаружения общей ошибки программирования (изменение при повторении).

* Note that the fail-fast behavior of an iterator cannot be guaranteed 
* as it is, generally speaking, impossible to make any hard guarantees in the 
* presence of unsynchronized concurrent modification. Fail-fast iterators 
* throw ConcurrentModificationException on a best-effort basis. 
* Therefore, it would be wrong to write a program that depended on this 
* exception for its correctness: the fail-fast behavior of iterators * should be used only to detect bugs. 

Таким образом

отказоустойчивость быстро, чтобы немедленно остановить множество нитей

не гарантируется. И любая несинхронизированная параллельная модификация может привести к неопределенному состоянию.