[concurrency-interest] readValueUnderLock in ConcurrentHashMap

Jason T. Greene jason.greene at redhat.com
Tue Apr 8 15:55:27 EDT 2008

Pavitar Singh wrote:
> Hi All,
> I didnt understand why do we need readUnderLock during get in
> ConcurrentHashMap.
> "This is possible only if a compiler happens to reorder a HashEntry
> initialization with its table assignment, which is legal under memory
> model          but is not known to ever occur."  from the javadoc.
> Does that mean :
> in put method .
> tab[index] will have a HashEntry , but not yet initialized (constructor
> invoked)

It means that the HashEntry will not be completely initialized. So the 
volatile variable read might see the default initial value, which is null.

> if this is the case then how HashEntry hash and key will be visible in:
> get method.
> if (e.hash == hash && key.equals(e.key))

Because they are final. Final fields are guaranteed to be visible as 
long as the object is not published before the constructor has 
completed. See 17.5 of the JLS:

Jason T. Greene
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list