-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b25
-
generic
-
generic
-
Not verified
Collections use a modCount field to track changes to data structures,
so they can throw ConcurrentModificationException if another thread
unexpectedly modifies the collection (rather than corrupting the data
and carrying on).
Some collections mark modCount as volatile; some do not.
Since the modCount mechanism comes with no guarantees, and users of
single-threaded collections do not expect to pay the (high) price
of a volatile write on every modification operation, the volatile
modifier should be removed.
Here are the uses of volatile to be removed:
./java/util/HashMap.java:177: transient volatile int modCount;
./java/util/IdentityHashMap.java:176: private transient volatile int modCount;
./java/util/WeakHashMap.java:185: volatile int modCount;
so they can throw ConcurrentModificationException if another thread
unexpectedly modifies the collection (rather than corrupting the data
and carrying on).
Some collections mark modCount as volatile; some do not.
Since the modCount mechanism comes with no guarantees, and users of
single-threaded collections do not expect to pay the (high) price
of a volatile write on every modification operation, the volatile
modifier should be removed.
Here are the uses of volatile to be removed:
./java/util/HashMap.java:177: transient volatile int modCount;
./java/util/IdentityHashMap.java:176: private transient volatile int modCount;
./java/util/WeakHashMap.java:185: volatile int modCount;