When given a choice, this pool always prefers adding a new thread rather than queueing if there are currently fewer than the current getMinimumPoolSize threads running, but otherwise always prefers queuing a request rather than adding a new thread. Thus, if you use an unbounded buffer, you will never have more than getMinimumPoolSize threads running.
If you are sure that this cannot happen, then you can instead supply a queue of some sort (for example, a BoundedBuffer or LinkedQueue) in the constructor. This will cause new commands to be queued in cases where all MaximumPoolSize threads are busy.
Michael Remijan wrote:...
This behavior is odd and I can't quite figure out why it works this way.
When I think of a thread pool, I think about a minimum number of threads sitting there waiting to process commands. A command goes in and it goes to a thread, if there are no threads available, start adding new threads until a maximum is reached. If the maximum is reached and commands are still coming in, then start queuing the requests. If the max of the queue is then reached, then some sort of rejection policy is consulted on what to do next. I'd like a pool which does this.