HashMap and visibility

Question

HashMap\'s javadoc states:

if the map is structurally modified at any time after the iterator is created, in any way except through the iterator\'s own re

Answer 1

If we will look into HashMap sources and compare them between Java 6 and Java 7 we will see such interesting difference:

transient volatile int modCount; in Java6 and just transient int modCount; in Java7.

I'm sure that it is cause for different behavior of mentioned code due to this:

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

UPD: It seems to me, that this is a known Java 6/7 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6625725 which was fixed in latest Java7.

UPD-2: Mr. @Renjith said, that he just tested and did not found any difference in behavior of HashMaps implementation. But I just tested it too.

My test was:

1) I have created HashMap2 class, which is absolutely copy of HashMap from Java 6.

One important thing is we need to introduce here 2 new fields:

transient volatile Set<K>        keySet = null;

and

transient volatile Collection<V> values = null;

2) Then I used this HashMap2 in test of this question and run it under Java 7

Result: it works like such test under Java 6, i.e. there isn't any ConcurentModificationException.

That all proves my conjecture. Q.E.D.

Answer 2

My theory is that on both Java 6&7, creating the iterator in the reader thread takes longer time than putting 100 entries in the writer thread, mainly because new classes have to be loaded and initialized (namely EntrySet, AbstractSet, AbstractCollection, Set, EntryIterator, HashIterator, Iterator)

So the writer thread has finished by the time this line is executed on the reader thread

    HashIterator() {
        expectedModCount = modCount;
        if (size > 0) { // advance to first entry

In Java 6, since modCount is volatile, the iterator sees the latest modCount and size, so the rest of iteration goes smoothly.

In Java 7, modCount is not volatile, the iterator probably sees stale modCount=3, size=3. After sleep(1), the iterator sees updated modCount, and fails immediately.

Some flaws with this theory:

1. the theory should predict MAX i=1 on java 7
2. before main() is executed, HashMap was probably iterated by other code, so the mentioned classes were probably loaded already.
3. reader thread seeing a stale modCount is possible, but not likely, since it's the first read of the variable on that thread; there's no prior cached value.

We may get to the bottom of this problem by planting logging code in Hashmap to find out what the reader thread is seeing.

Answer 3

As a side note, ConcurrentModificationException (despite the unfortunate name) is not intended to detect modification across multiple threads. it is only intended to catch modifications within a single thread. the effects of modifying a shared HashMap across multiple threads (without correct synchronization) are guaranteed to be broken regardless of the use of iterators or anything else.

In short, your test is bogus regardless of the jvm version and it is only "luck" that it does anything different at all. for example, this test could throw NPE or some other "impossible" exception due to the HashMap internals being in an inconsistent state when viewed cross thread.