concurrenthashmap java

Question

This seems wrong.

        static ConcurrentHashMap k; //multiple threads have access to k
         X o = k.get("LL");
         o.a = 6;

If multiple threads access k concurrently, and get k("LL"), then update (oa = #) without k.put("ll",o), without synchronizing on 'o', or on 'k' what happens?

Answer 1

The ConcurrentHashMap guarantees that getting a value is atomic, but it can't control what you do with the values you get from it. Modifying values in the hashmap is fine from the ConcurrentHashMap's view but may still not result in the behaviour you want. To be sure about thread-safety you need to consider exactly what each thread that has access to it does.

Putting the value back in the ConcurrentHashMap seems redundant and doesn't make the whole operation any safer. You're already modifying the object outside of any synchronization.

Additional synchronization may be necessary, but I can't tell for sure without seeing more context.

Answer 2

A ConcurrentMap has conditional operations that guarantee atomic insert/removal and replacement of key/value pairs. Additionally, accessing a ConcurrentMap creates a happens-before relationship so you can make certain guarantees about the ordering of your code.

In the code presented, the line:

X o = k.get("LL");

accesses the current X value for the key "LL". The next line modifies the a property. Without knowing the implementation of X, this is Java so we know that there is no method call here. If (and only if) the a property is marked as volatile then some subsequent code accessing the X at "LL" will see the a value as 6. If it isn't volatile then there are no guarantees at all. They will probably see 6, particularly on an SMP x86 box, with not many threads doing much at the time. In production, on a big NUMA box, they are less likely to. Mutability brings with it all sorts of complications and difficulty.

Generally, you'll find it is easier to reason about the state the map is in if you use immutable keys AND values.

Answer 3

Simply speaking:

  o.a=6

is an atomic operation, all the threads will compete, and the last thread setting it will "win", overwriting the value.

More specifically, the ConcurrentHashMap only guarantees that the link between a key and its associated value is handled taking multiple threads into account - ie put and get are atomic .

This does not prevent any thread from modifying attributes of the value once it gets a reference to it!