Combining the fixed and cached thread pools

Question

Is there a way to 'combine' the behavior of cached and fixed thread pools ? I have a requirement where
- at startup, I need to execute a fixed number of short-lived tasks at the background
- after startup, on demand, I need to run one short-lived task at a time
If I use a fixed thread pool for my startup processing, it creates the fixed number of threads to process the tasks. But subsequently, those many threads are not required since my task submission is going to be one at a time. The remaining (n-1) threads therefore are really sitting idle & useless.
If I use a cached thread pool, then I cannot constrain the number of threads to run at startup (since it creates one for each task). Though it ends up taking those threads out after they are idle for a fixed period. But I'm worried that it might create many threads and possibly slowing down the startup ?
Is there a way to create a pool with a fixed number of threads but 'remove' a set of threads when they are idle ?
TIA

Answer 1

v_bala wrote:
Thanks. The SynchronousQueue worked as expected. But I tried a LinkedBlockingQueue with size 1 hoping that would cause the second task submission to cause a new thread creation. It didn't. Instead it queues up the request (maybe the doc in ThreadPoolExecutor says that when it mentions "If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread"). I suppose if I were to try another it would create another thread ? (I was testing with only two tasks - the first one ended up creating a thread for the task and the next got queued since the queue capacity is 1)yes, the TPE will not start adding threads until the queue starts rejecting them. kind of odd in my opinion, but that's how it works.
Btw, that was an interesting idea to add a task that scale the core pool number down ! Currently it comes back down to just the one thread (my core pool size is one) after the idle timeout but your idea may give me a slightly better response since it will scale down the core pool size quicker....I suppose if there was a task submission before that idle time there maybe a performance hit (but I don't anticipate that in my case )?actually, that won't scale things down any faster. changing the core pool size will not ditch the other threads immediately, they will still stick around until they idle timeout. changing the core pool size allows you to not worry about the queue implementation (the first solution). you can set the initial core pool size to your "max" size on startup, then drop it down for the normal processing, all the while using a linkedblockingqueue of unlimited size.