Question

Currently I have a construct that does the following:
An X number of threads (X being a configurable variable from the user) are all started and await for a task to become available. The threads block waiting in
a BlockingQueue.
Another thread(s) places task(s) in the blocking queue and the blocked threads take the task(s) and run them and go back to wait for the next task.
Anyway this works fine but I have the following issue. X threads are constantly waiting for a task even if there isn’t any for 2 hours.
Also X threads are actually available even if there are only lets’say X/50 tasks coming in (i.e. I have much more threads than I actually need).
So my question is, how could I refactor this (perhaps using Executors) so that X goes up and down as needed?
My aim is not to lose performance. I mean now I could have more threads than I would need (wasting resources) but I don’t have the overhead of creating new threads.
I am interested in refactoring this in a way to not waste resources and keep the same performance levels.

Answer 1

Normal ThreadPoolExecutor should suffice. The basic constructor takes parameters for “core pool size” (minimum amount of threads to keep alive at all times), maximum size (maximum amount of threads) and the keep alive time of excess threads (idle threads above core pool size). Also, you can pass your BlockingQueue straight for the executor.