ThreadPoolExecutor with dynamic sizing

Question

ExecutorService executor = new
ThreadPoolExecutor(1, 5, 10, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>());with the above piece of code in our application, the number of processor/active threads doesn't go above 1.
when i analyzed the behavior with a profiling tool, i see that there is no more free time for the single thread to process the runnable tasks. In this case why doesn't the executor let one (or more) threads to work on the runnables that are piling up the queue and then (later when the queue is nearing empty) shutdown the extra threads (after waiting for the given 10 seconds).
or i got the concept wrong?

Answer 1

Let's answer a few of your questions:
kramasundar wrote:
1. How (using which metric/statistics) does the executor decide that it has to create a new thread (say the second or third or fourth or fifth thread)?
currently i am looking into the JDK implementation to figure this out.The executors don't use any statistics or metrics. It is quite simple, and defined in the API: ThreadPoolExecutor
1) If the number of threads is less than the corePoolSize, create a new Thread to run a new task
2) If the number of threads is equal (or greater than) the corePoolSize, put the task into the queue
3) If the queue is filled, and the number of threads is less than the maxPoolSize, create a new thread to run tasks in.
4) If the queue is filled, and the number of threads is greater than or equal to maxPoolSize, reject the task.
kramasundar wrote:
I didn't know the magic behind the SynchronousQueue. ...
In the case of LinkedBlockingQueue we dont have to care about the size issue right?There is no magic. With SynchronousQueue, the queue has no capacity. which means the queue is 'always filled' which means new threads will be created up through the maxPoolSize. Then, when new tasks get added, if there isn't an idle thread they get rejected.
For the LinkedBlockingQueue, the queue is unbounded, it never gets filled. Which means new threads will ONLY be created up through the corePoolSize, after which all your tasks get queued up. This is important in your case because you keep using a corePoolSize of 1 with an unbounded queue - so no more than 1 thread will be used.
kramasundar wrote:
2. Here the executor created 1 thread only. Also i could see that one thread was not enough to handle the load. The throughput was ~ 4000 TPS (i am telling you this since the next run 3 runs fine with higher TPS).
_executor = new ThreadPoolExecutor(1, 20, 60, TimeUnit.SECONDS,
new ArrayBlockingQueue<Runnable>(100), new SimpleThreadFactory());3. Here the executor created 15 threads (but not more). Nevertheless the TPS is higher ~12000 TPS. This run confirms that in run 2 Executor could have spawned some more threads to increase the TPS.
_executor = new ThreadPoolExecutor(15, 20, 60, TimeUnit.SECONDS,
new ArrayBlockingQueue<Runnable>(100), new SimpleThreadFactory());Does the above runs conclude that in run 2 a queue of size 100 is never full. If it had been full atleast once then the executor would have spawned another thread?First: "This run confirms that in run 2 Executor could have spawned some more threads to increase the TPS."
No, this confirms that you could configure the executor to run more threads. The executor can't do more than what it is configured to do. It can't spawn new threads to increase your metric of speed, it can only create threads following its own, well defined set of rules.
Now, " Does the above runs conclude that in run 2 a queue of size 100 is never full. If it had been full atleast once then the executor would have spawned another thread?"
That is the conclusion I would make, yes. As Kajbj said, otherwise you would see rejected executions.