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 remove method, the iterator will throw a ConcurrentModificationException.

I built a sample code that, based on the specification, is supposed to fail almost immediately and throw a ConcurrentModificationException;

• It does fail immediately as expected with Java 7
• but it (seems to) always work with Java 6 (i.e. it does not throw the promised exception).

Note: it sometimes does not fail with Java 7 (say 1 time out of 20) - I guess it has to do with thread scheduling (i.e. the 2 runnables are not interleaved).

Am I missing something? Why does the version run with Java 6 not throw a ConcurrentModificationException?

In substance, there are 2 Runnable tasks running in parallel (a countdownlatch is used to make them start approximately at the same time):

• one is adding items to the map
• the other one is iterating over the map, reading the keys and putting them into an array

The main thread then checks how many keys have been added to the array.

Java 7 typical output (the iteration fails immediately):

java.util.ConcurrentModificationException
MAX i = 0

Java 6 typical output (the whole iteration goes through and the array contains all the added keys):

MAX i = 99

Code used:

public class Test1 {

    public static void main(String[] args) throws InterruptedException {
        final int SIZE = 100;
        final Map<Integer, Integer> map = new HashMap<Integer, Integer>();
        map.put(1, 1);
        map.put(2, 2);
        map.put(3, 3);
        final int[] list = new int[SIZE];
        final CountDownLatch start = new CountDownLatch(1);
        Runnable put = new Runnable() {
            @Override
            public void run() {
                try {
                    start.await();
                    for (int i = 4; i < SIZE; i++) {
                        map.put(i, i);
                    }
                } catch (Exception ex) {
                }
            }
        };

        Runnable iterate = new Runnable() {
            @Override
            public void run() {
                try {
                    start.await();
                    int i = 0;
                    for (Map.Entry<Integer, Integer> e : map.entrySet()) {
                        list[i++] = e.getKey();
                        Thread.sleep(1);
                    }
                } catch (Exception ex) {
                    ex.printStackTrace();
                }
            }
        };
        ExecutorService e = Executors.newFixedThreadPool(2);
        e.submit(put);
        e.submit(iterate);
        e.shutdown();

        start.countDown();
        Thread.sleep(100);
        for (int i = 0; i < SIZE; i++) {
            if (list[i] == 0) {
                System.out.println("MAX i = " + i);
                break;
            }
        }
    }
}

Note: using JDK 7u11 and JDK 6u38 (64 bits version) on an x86 machine.

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

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.