"Volatile" в "HashMap" о "modCount"

Question

Почему HashMap не использует volatile для изменения modCount, чтобы убедиться, что поток может сразу узнать об изменении Map, когда другой поток его изменит?

Фрагмент ниже:

/**
 * The number of times this HashMap has been structurally modified
 * Structural modifications are those that change the number of mappings 
in
 * the HashMap or otherwise modify its internal structure (e.g.,
 * rehash).  This field is used to make iterators on Collection-views of
 * the HashMap fail-fast.  (See ConcurrentModificationException).
 */
transient int modCount;

Answer 1

Единственным преимуществом объявления modCount как volatile было бы ускорение быстрого обнаружения сбоя одновременных изменений ... в некоторых случаях:

• ДляHashMap, который ограничен потоком (т. е. используется только одним потоком), функциональных преимуществ нет.Поток гарантированно увидит обновления, которые он делает для modCount.

• Для HashMap, который не ограничен потоком, но (должным образом) синхронизирован каким-либо другим способом, синхронизация должнаубедитесь, что modCount не устарел при просмотре из другого потока, чем тот, который его обновил.Опять же, никаких функциональных преимуществ.

• Для HashMap, который не ограничен потоком и не синхронизирован должным образом, вы делаете это неправильно, и у вас гораздо большие проблемы ¹ беспокоиться о том, что «быстрое сбой» обнаружения одновременных изменений не является немедленным.Таким образом, выгода ... предельная.

И противоположность вышесказанному заключается в том, что объявление modCount равным volatile приведет к влечению за снижение производительности(в виде барьеров памяти и дополнительной памяти для чтения и записи) для всех операций HashMap, которые читают или записывают это поле.(И это большинство из них.)

В итоге: ноль или минимальное преимущество по сравнению с накладными расходами производительности, которые могут быть значительными в некоторых случаях использования.

---

^{1 - дляНапример, heisenbug HashMap Повреждения.}