Multi threading with CachedThreadPool
The thread pool is not storing messages on a queue; it is storing Runnable tasks.  However, each Runnable task has access to the effectively final StringBuffer message variable from the calling context.
See this StackOverflow question.  Each is a ThreadPoolExecutor, just with different parameters to control how many threads are created and the type of queue.  I would lean in favour of the FixedThreadPool with 1 thread for each CPU core, but many other factors can and will impact that; profile to be sure.
No.  Making processMessage() synchronized will mean you are single threaded ... worse, because the overhead of multiple threads being scheduled to process the task queue in a single threaded fashion.   At 150 messages/10 seconds, with one thread the function would need to complete in 66ms.  If you have 8 cores, with 1 thread per core, each thread could take a leisurely 500ms to process the message, as long as they can run independently.  You may have parts of processMessage that you may need to make synchronized, but you’ll want to make those regions as small and fast as possible.


Other comments:

A StringBuffer is a mutable object;  since message is being passed to another thread, for safety, I’d want the message to be transformed into a immutable String so the caller doesn’t clear the message buffer while the executor thread is processing it.

processMessage() does not need to be public; private would be more appropriate. 

It looks like executor should be private and final as well.