客户端/服务器多线程和ConcurrentHashMap-为什么没有将client.get（id）锁定？

Question

I have the following block of code in my server:

clients.putIfAbsent(id, new Integer(0));
synchronized (clients.get(id)) {
    if (o instanceof Integer) {
        x = new Integer(((Integer) o).intValue());
        value = clients.get(id); // existing value in HashMap
        value = new Integer(value.intValue() + x);
        clients.put(id, value);
    } else if (o instanceof String) {
        clients.put(id, new Integer(0));
    }
    Thread.sleep(SockServer5.sleepTime);
out.writeObject(clients.get(id));
    out.flush();
}

clients is a ConcurrentHashMap, while o is the object input being read from the client. For each new client connection, the server spawns a new thread.

I would like to know, is there any particular reason why my clients.get(id) isn't being locked?

Answer 1

It is really hard to understand what you are trying to achieve, clients.get(id) returns an instance of an Object and you are synchronizing on it.

Fine.

That does not prevent access to the concurrent hashmap by another thread. I suspect you want to prevent access to the Hashmap, in which case you should use an Object() as a mutex

Answer 2

In both branches of your if statement, you are putting a new object into the map. Therefore all other threads will find a different object as result of client.get(id). Even if you have two equal integers in the map, they are not same objects. Example: if 'o' is always a string, each execution of the code will replace the value in the map, and each following thread will get a new object in client.get() (well some may be lucky enough to get a previous object, but most will get a new one, since the synchronized block is rather small and fast comparing to stream handling and your sleep (because the object gets replaced, before the sleep finishes)).

If you want to synchronize on a non-existing object, on the idea (or id) of the object, check out this github repo: https://github.com/anotheria/idbasedlock

Answer 3

Two things: first

One shall not use new Integer but Integer.valueOf(i)

The other thing is that there isn't even a need to use synchronized. It completely defies the reason to use a concurrent map, because it throttles down threads to single-threaded thanks to blocking. Here is a solution that does not use synchronized but is still thread-safe:

clients.putIfAbsent(id, Integer.valueOf(0));

Integer value;
do {
  value = clients.get(id);
} while (clients.replace(id, value, value + o) == false); // repeat until value did not change in between

Thread.sleep(SockServer5.sleepTime);
out.writeObject(value);
out.flush();

Where clients is defined as (replace String with whatever you use):

final ConcurrentHashMap<String, Integer> clients;

This uses the same concept as compareAndSet does in other Atomics: it repeats until no thread interfered in between. The big benefit is that no thread needs to be blocked, so on a multi-core machine all cores can be used at 100% all the time .

Please note as well the usage of automatic boxing of Integers in value + o . Java will use the most efficient form here on its own.