Is HashMap.put() atomic?

[Joe Joseph]

Hi,

I have a Question. Consider that i have a global HashMap hashMap1. If 1 execute the below statment, it will insert a new entry with key = "k1" (If the key wasnt there) or it will replace the value for "k1" with hashMap2, if the key "k1" is already there.
hashMap1.put("k1",hashMap2);
Thus I assume that during the time when hashMap1.put("k1",hashMap2); is being executed there would be no time when hashMap1.doesnt contain the key "k1".
To make the question clearer, can i assume that
hashMap1.put("k1",hashMap2) is an atomic operation, i.e hashMap1.put() doesnt internally consist of a remove() and then put(). If it internally consist of a remove() and then put(), then for the small inverval between the remove() and put(), the key "k1" wont have a value.
Please let me know

[Paul Clapham]

No, you cannot assume that will be an atomic operation. The Java language specification describes what operations are atomic, and they are all simple things like assigning an int. Complex things like what you describe are not atomic. If you need them to be, then you need to synchronize access to those operations.

[Henry Wong]

If it internally consist of a remove() and then put(), then for the small inverval between the remove() and put(), the key "k1" wont have a value.

No... it is not atomic. And it is worse than you think. During a small interval during the operation, the interal references of the hashmap may not even be valid. If you try to get(), while a put() is happening, you can get k1, or you can not get k1, or the map may just not work.

Henry
[ November 06, 2007: Message edited by: Henry Wong ]

[Jim Yingst]

Yes, if the put() happens to cause the HashMap to resize itself and copy its contents into a new, larger array, then you can get some completely nonsensical results, including NullPointerException or ArrayIndexOutOfBounds. If you want to use a HashMap from multiple threads, you must either (a) not change its data, (b) use synchronization, or (c) use a ConcurrentHashMap from JDK 5 or later. Using synchronization may also be accomplished by using Collections.synchronizedMap() or using Hashtable, but in each of these cases you may need additional synchronization - do not assume that just because the individual methods are synchronized, that all problems are solved.

[Joe Joseph]

I looked up the code begin HashMap.put(). I have give the code below

 
/**
     * Associates the specified value with the specified key in this map.
     * If the map previously contained a mapping for this key, the old
     * value is replaced.
     *
     * @param key key with which the specified value is to be associated.
     * @param value value to be associated with the specified key.
     * @return previous value associated with specified key, or <tt>null</tt>
     *       if there was no mapping for key.  A <tt>null</tt> return can
     *       also indicate that the HashMap previously associated
     *       <tt>null</tt> with the specified key.
     */
    public Object put(Object key, Object value) {
        Object k = maskNull(key);
        int hash = hash(k);
        int i = indexFor(hash, table.length);
 
        for (Entry e = table[i]; e != null; e = e.next) {
            if (e.hash == hash && eq(k, e.key)) {
                Object oldValue = e.value;
                e.value = value;
                e.recordAccess(this);
                return oldValue;
            }
        }
 
        modCount++;
        addEntry(hash, k, value, i);
        return null;
    }

From the statement "e.value = value;", isnt it apparent that will either have the old value or the new value at any point of time??

[ added code tags - Jim ]
[ November 06, 2007: Message edited by: Jim Yingst ]

[Jim Yingst]

[Joe]: From the statement "e.value = value;", isnt it apparent that will either have the old value or the new value at any point of time??

At that instant, yes. But there are plenty of things that could have gone wrong before that, and a few things that can go wrong after that. If a rehash is occurring, then the entire chain of enries for th at bucket (all the entries obtained by following e.next) will be reprocessed and put in different buckets. So while following that chain you could start in one bucket and end up in another, while the entry you're looking for could end up in yet a different bucket. So you'd never find the entry you're looking for, even though it's in the hashmap.
[ November 06, 2007: Message edited by: Jim Yingst ]