HashMap and visibility | 易学教程

问题

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.

回答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.

回答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.

回答3:

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:

the theory should predict MAX i=1 on java 7
before main() is executed, HashMap was probably iterated by other code, so the mentioned classes were probably loaded already.
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.

来源：https://stackoverflow.com/questions/14363123/hashmap-and-visibility

标签

java

multithreading

hashmap