Java 8 ConcurrentHashMap

Short answer

The Node#val is volatile which establishes your happens before ordering.

Longer answer

synchronized isn't a requirement for thread safety, it's one tool in a toolbox to make a system thread safe. You'll have to consider an entire set of actions on this ConcurrentHashMap to reason about thread safety.

It's useful to know the original ConcurrentHashMap too is non-blocking. Notice pre-Java 8 CHM get

V get(Object key, int hash) { if (count != 0) { // read-volatile HashEntry<K,V> e = getFirst(hash); while (e != null) { if (e.hash == hash && key.equals(e.key)) { V v = e.value; if (v != null) return v; return readValueUnderLock(e); // ignore this } e = e.next; } } return null; } 

In this case, there is no blocking, so how does it work? The HashEntry#value is volatile. That is the synchronization point for thread safety.

The Node class for CHM-8 is the same.

static class Node<K,V> implements Map.Entry<K,V> { final int hash; final K key; volatile V val; volatile Node<K,V> next; 

So a non-null val in this case should ensure thee happens-before relationship with respect to actions prior to a put.

The documentation does not state that synchronization occurs. For example it states

[...] aggregate operations such as putAll and clear, concurrent retrievals may reflect insertion or removal of only some entries.

In other words, there is a difference between allowing concurrent usage, and providing synchronized access.

The Java Language Specification writes:

If we have two actions x and y, we write hb(x, y) to indicate that x happens-before y.

• If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).

• There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object.

• If an action x synchronizes-with a following action y, then we also have hb(x, y).

• If hb(x, y) and hb(y, z), then hb(x, z).

and defines

Synchronization actions induce the synchronized-with relation on actions, defined as follows:

• An unlock action on monitor m synchronizes-with all subsequent lock actions on m (where "subsequent" is defined according to the synchronization order).

• A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread (where "subsequent" is defined according to the synchronization order).

• An action that starts a thread synchronizes-with the first action in the thread it starts.

• The write of the default value (zero, false, or null) to each variable synchronizes-with the first action in every thread.

  Although it may seem a little strange to write a default value to a variable before the object containing the variable is allocated, conceptually every object is created at the start of the program with its default initialized values.

• The final action in a thread T1 synchronizes-with any action in another thread T2 that detects that T1 has terminated.

  T2 may accomplish this by calling T1.isAlive() or T1.join().

• If thread T1 interrupts thread T2, the interrupt by T1 synchronizes-with any point where any other thread (including T2) determines that T2 has been interrupted (by having an InterruptedException thrown or by invoking Thread.interrupted or Thread.isInterrupted).

That is, reading a volatile field establishes happens-before just like an explicit lock.