Is there a way to ensure that threads are assigned to a specified set of objects?

[Is] dedicating worker threads to a particular set of objects is a better/faster approach?

I assume the overall goals is to trying to maximize the concurrent processing of these inbound messages. You have receivers from the 3 sources, that need to put the messages in a pool that will be optimally handled. Because messages from any of the 3 sources may deal with the same target object which cannot be processed simultaneously, you want someway to divide up your messages so they can be processed concurrently but only if they are guaranteed to not refer to the same target object.

I would implement the hashCode() method on your target object (maybe just name.hashCode()) and then use the value to put the objects into an array of BlockingQueues, each with a single thread consuming them. Using an array of Executors.newSingleThreadExecutor() would be fine. Mod the hash value mode by the number of queues and put it in that queue. You will need to pre-define the number of processors to maximum. Depends on how CPU intensive the processing is.

So something like the following code should work:

 private static final int NUM_PROCESSING_QUEUES = 6;
 ...
 ExecutorService[] pools = new ExecutorService[NUM_PROCESSING_QUEUES];
 for (int i = 0; i < pools.length; i++) {
    pools[i] = Executors.newSingleThreadExecutor();
 }
 ...
 // receiver loop:
 while (true) {
    Message message = receiveMessage();
    int hash = Math.abs(message.hashCode());
    // put each message in the appropriate pool based on its hash
    // this assumes message is runnable
    pools[hash % pools.length].submit(message);
 }

One of the benefits of this mechanism is that you may be able to limit the synchronization about the target objects. You know that the same target object will only be updated by a single thread.

Do people agree with the assumption that dedicating worker threads to a particular set of objects is a better/faster approach?

Yes. That seems the right way to get optimal concurrency.

Assuming this is a better approach, do the existing Java ThreadPool classes have a way to support this? Or does it require us coding our own ThreadPool implementation?

I don't know of any thread-pool which accomplishes this. I would not write your own implementation however. Just use them like the code outlines above.

In general, approaches like this are a bad idea. It falls under the "don't optimize early" mantra.

Further, if implemented your idea may harm your performance, not help it. One simple example of where it wouldn't work well is if you suddenly got a lot of requests on one type - the other worker thread would be idle.

The best approach is to use a standard producer-consumer pattern and tune the number of consumer threads by system testing under various loads - ideally by feeding in a recording of real-life transactions.

The "go to" framework for these situation are classes from the java.util.concurrent package. I recommend using a BlockingQueue (proably an ArrayBlockingQueue) with an ExecutorService created from one of the Executors factory methods, probably newCachedThreadPool().

Once you have implemented and system tested that, if you find proven performance problems, then analyse your system, find the bottleneck and fix it.

The reason you shouldn't optimize early is that most times the problems are not where you expect them to be