So I have worked with Multithreading in small application. Create a new thread here, a new thread there.
I'm currently working on a program that monitors an IRC chat. For every valid command it creates a thread, does some work, and outputs the result to the chat. At times the application will get 10 or more valid commands in a short time and 10 or more threads are created. The application starts to really slow down. I've read that creating and closing threads is very cost inefficient with resources so I want to change my method.
An idea I've had is to create some threads (5 or so?) that are always running with a method that I pass commands to that queues them in a FIFO basis. Before I implemented this I wanted to see if there is something better I should be using. I don't want to run off and reinvent the wheel, of course.
You can use a fixed size ExecutorService thread poll. Submit each message to send as a task and they will be sent as there is a free thread. e.g.
ExecutorService es = Executors.newFixedThreadPool(5);
Note: this can lead to messages being sent out of order so your client should be able to reorder the messages based on a timestamp.
BTW: If 10 command at once is notably slow, it's not the creating of threads which will be causing this. Threads are expensive yes, but not that expensive. Instead it is likely to network delays or some other blocking operation. You may need to create qa queue for each client if you have poor network connections.