Java如何实现对ConcurrentHashMap读取的锁定

Question

TL;DR: in Java I have N threads, each using a shared collection. ConcurrentHashMap allows me to lock on write, but not on read. What I need is to lock a specific item of the collection, read the previous data, do some computation, and update the values. If two threads receive two messages from the same sender, the second thread has to wait for the first one to finish, before doing its stuff.

---

Long version:

These threads are receiving chronologically ordered messages, and they have to update the collection basing on a messageSenderID .

My code simplified is as follow:

public class Parent {
    private Map<String, MyObject> myObjects;

    ExecutorService executor;
    List<Future<?>> runnables = new ArrayList<Future<?>>();

    public Parent(){
        myObjects= new ConcurrentHashMap<String, MyObject>();

        executor = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 10; i++) {
            WorkerThread worker = new WorkerThread("worker_" + i);
            Future<?> future = executor.submit(worker);
            runnables.add(future);
        }
    }

    private synchronized String getMessageFromSender(){
        // Get a message from the common source
    }

    private synchronized MyObject getMyObject(String id){
        MyObject myObject = myObjects.get(id);
        if (myObject == null) {
            myObject = new MyObject(id);
            myObjects.put(id, myObject);
        }
        return myObject;
    }

    private class WorkerThread implements Runnable {
        private String name;

        public WorkerThread(String name) {
            this.name = name;
        }

        @Override
        public void run() {
            while(!isStopped()) {
                JSONObject message = getMessageFromSender();
                String id = message.getString("id");
                MyObject myObject = getMyObject(id);
                synchronized (myObject) {
                    doLotOfStuff(myObject);
                }
            }
        }
    }
}

So basically I have one producer and N consumers, to speed-up processing, but the N consumers have to deal with a common base of data and chronological order has to be respected.

I am currently using a ConcurrentHashMap , but I'm willing to change it if needed.

The code seems to work if messages with same ID arrive enough apart (> 1 second), but if I get two messages with the same ID in the distance of microseconds, I get two threads dealing with the same item in the collection.

I GUESS that my desired behavior is:

Thread 1                        Thread 2
--------------------------------------------------------------
read message 1
find ID
lock that ID in collection
do computation and update
                                read message 2
                                find ID
                                lock that ID in collection
                                do computation and update

While I THINK that this is what happens:

Thread 1                        Thread 2
--------------------------------------------------------------
read message 1
                                read message 2
                                find ID
                                lock that ID in collection
                                do computation and update
find ID
lock that ID in collection
do computation and update

I thought about doing something like

JSONObject message = getMessageFromSender();
synchronized(message){
    String id = message.getString("id");
    MyObject myObject = getMyObject(id);
    synchronized (myObject) {
        doLotOfStuff(myObject);
    } // well maybe this inner synchronized is superfluous, at this point
}

But I think that would kill the whole purpose of having a multithreaded structure, since I would read one message at a time, and the workers are not doing anything else; and it would be like if I was using a SynchronizedHashMap instead of a ConcurrentHashMap.

---

For the record, I report here the solution I implemented eventually. I'm not sure it is optimal and I still have to test for performances, but at least the input is handed properly.

public class Parent implements Runnable {

    private final static int NUM_WORKERS = 10;
    ExecutorService executor;
    List<Future<?>> futures = new ArrayList<Future<?>>();
    List<WorkerThread> workers = new ArrayList<WorkerThread>();

    @Override
    public void run() {
        executor = Executors.newFixedThreadPool(NUM_WORKERS);
        for (int i = 0; i < NUM_WORKERS; i++) {
            WorkerThread worker = new WorkerThread("worker_" + i);
            Future<?> future = executor.submit(worker);
            futures.add(future);
            workers.add(worker);
        }

        while(!isStopped()) {
            byte[] message = getMessageFromSender();
            byte[] id = getId(message);
            int n = Integer.valueOf(Byte.toString(id[id.length-1])) % NUM_WORKERS;
            if(n >= 0 && n <= (NUM_WORKERS-1)){
                workers.get(n).addToQueue(line);
            }
        }
    }

    private class WorkerThread implements Runnable {
        private String name;
        private Map<String, MyObject> myObjects;
        private LinkedBlockingQueue<byte[]> queue;

        public WorkerThread(String name) {
            this.name = name;
        }

        public void addToQueue(byte[] line) {
            queue.add(line);
        }

        @Override
        public void run() {
            while(!isStopped()) {
                byte[] message= queue.poll();
                if(line != null) {
                    String id = getId(message);
                    MyObject myObject = getMyObject(id);
                    doLotOfStuff(myObject);
                }
            }
        }
    }
}

Answer 1

Conceptually this is kind of routing problem. What you need to is:

Get your your main thread (single thread) reading messages of the queue and push the data to a FIFO queue per id. Get a single thread to consume messages from each queue.

Locking examples will (probably) not work as after the second message order is not guaranteed even if fair=true .

From Javadoc: Even when this lock has been set to use a fair ordering policy, a call to tryLock() will immediately acquire the lock if it is available, whether or not other threads are currently waiting for the lock.

One thing for you to decide is if you want to create aa thread per queue (which will exit once the queue is empty) or keep the fixed size thread pool and manage get the extra bits to assign threads to queues.

So, you get a single thread reading from the original queue and writing to the per-id-queues and the you also get one thread per id reading from individual queues. This will ensure task serialization.

In terms of performance, you should see significant speed-up as long as the incoming messages have a nice distribution (id-wise). If you get mostly same-id messages then task will be serialized and also include the overhead for control object creation and synchronization.

Answer 2

You could use a separate Map for your locks. There's also a WeakHashMap that will automatically discard entries when the key is no longer present.

static final Map<String, Lock> locks = Collections.synchronizedMap(new WeakHashMap<>());

public void lock(String id) throws InterruptedException {
    // Grab a Lock out of the map.
    Lock l = locks.computeIfAbsent(id, k -> new ReentrantLock());
    // Lock it.
    l.lockInterruptibly();
}

public void unlock(String id) throws InterruptedException {
    // Is it locked?
    Lock l = locks.get(id);
    if ( l != null ) {
        l.unlock();
    }
}

Answer 3

I think you have the right idea with your synchronized blocks, except you mis-analyze a bit and go too far in any case. The outer synchronized block shouldn't force you into dealing with only one message at a time, it just keeps multiple threads from accessing the same message at once. But you don't need it. You really only need that inner synchronized block, on the MyObject instance. That will ensure that only one thread at a time can access any given MyObject instance, while enabling other threads to access messages, the Map and other MyObject instances as much as they want.

JSONObject message = getMessageFromSender();
String id = message.getString("id");
MyObject myObject = getMyObject(id);
synchronized (myObject) {
    doLotOfStuff(myObject);
}

If you don't like that, and the updates to the MyObject instances all involve single-method invocations, then you could just synchronize all of those methods. You still retain concurrency in the Map , but you're protecting the MyObject itself from concurrent updates.

class MyObject {
  public synchronize void updateFoo() {
    // ...
  }

  public synchronize void updateBar() {
    // ...
  }
}

When any Thread accesses any updateX() method it will automatically lock out any other Thread from accessing that or any other synchronized method. That would be simplest, if your updates match that pattern.

If not, then you'll need to make all of your worker Threads cooperate by using some sort of locking protocol. The ReentrantLock that OldCurmudgeon suggests is a good choice, but I would put it on MyObject itself. To keep things ordered properly, you should use the fairness parameter (see http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantLock.html#ReentrantLock-boolean- ). "When set true, under contention, locks favor granting access to the longest-waiting thread."

class MyObject {
  private final ReentrantLock lock = new ReentrantLock(true);

  public void lock() {
    lock.lock();
  }

  public void unlock() {
    lock.unlock();
  }

  public void updateFoo() {
    // ...
  }

  public void updateBar() {
    // ...
  }
}

Then you could update things like this:

JSONObject message = getMessageFromSender();
String id = message.getString("id");
MyObject myObject = getMyObject(id);
myObject.lock();
try {
    doLotOfStuff(myObject);
}
finally {
    myObject.unlock();
}

The important takeaway is that you don't need to control access to the messages, nor the Map . All you need to do is ensure that any given MyObject is being updated by at most one thread at a time.

Answer 4

You could get some speedup if you split up the JSON parsing from the doLotsOfStuff() . One thread listens for messages, parses them, then puts the parsed message on a Queue to maintain chronological order. A second thread reads from that Queue and doesLotsOfStuff with no need for locking.

However, since you apparently need more than a 2X speedup this is probably insufficient.

Added

Another possibility is multiple HashMaps. For example, if all the IDs are ints, make 10 HashMaps for IDs ending with 0,1,2... Incoming messages get directed to one of 10 threads, which parse the JSON and update their relevant Map. Order is maintained within each Map, and there are no locking or contention issues. Assuming the message IDs are randomly distributed this yields up to a 10x speedup, though there is one extra layer of overhead to get at your Map. eg

Thread JSON                     Threads 0-9
--------------------------------------------------------------
while (notInterrupted) {
   read / parse next JSON message
   mapToUse = ID % 10
   pass JSON to that Thread's queue
}
                                while (notInterrupted) {
                                   take JSON off queue
                                   // I'm the only one with writing to Map#N
                                   do computation and update ID
                                }

Answer 5

Actually here is a design idea: when a consumer takes a request to work on your Object it should actually remove the object with that ID from your list of Objects and then re-insert it back once the processing is done. Then any other consumer getting request to work on the object with the same id should be in blocking mode waiting for the object with that ID to re-appear in your list. You will need to add a management to keep record of all existing objects so when you can distinguish between the object that exists already but is not currently in the list (ie being processed by some other consumer) and the object that does not exist yet.