We are working on an application where a set of objects can be affected by receiving messages from 3 different sources. Each message (from any of the sources) has a single objec
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