Will the count of simultaneously running thread in a fixed-size thread pool be always less than corePoolSize unless the queue is full?

0
votes

The javadoc says:

When a new task is submitted [...], and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle. If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. By setting corePoolSize and maximumPoolSize the same, you create a fixed-size thread pool. By setting maximumPoolSize to an essentially unbounded value such as Integer.MAX_VALUE, you allow the pool to accommodate an arbitrary number of concurrent tasks.

Does it mean that the count of simultaneously running thread in a fixed-size thread pool will be always less than corePoolSize unless the queue is full?

1
javathreadpoolexecutor
No. Suppose maximumPoolSize threads have started to handle a full queue, but no new tasks come in. As tasks complete, you will reach a point where the corePoolSize < numberOfThreadsRunning < maximumPoolSize. - bradimus
@bradimus, so this can occur only after the queue at least once completely filled, can't it? - Ksenia
I believe that is correct. - bradimus
@bradimus We are talking fixed-sized pools here... corePoolSize strictly inferior to maximumPoolSize is not possible by definition, what am I missing ? - GPI
@GPI Who mentioned fixed-size pools? The javadoc in the OP specifically discusses creating new threads: "If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full." Tell me, how is it possible for there to be more than corePoolSize but less than maximumPoolSize threads running if corePoolSize is not strictly less than maximumPoolSize? - bradimus

1 Answers

1
votes

Does it mean that the count of simultaneously running thread in a fixed-size thread pool will be always less than corePoolSize unless the queue is full?

No, it does not.

Semantic approach

As I read it, and for fixed size pools, this quote states nothing about the number of active threads specifically with respect to the size of the queue. The only sentence tying the two is this one :

If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full.

Which does not apply, since in a fixed-size pool has corePoolSize equal to maximumPoolSize. The "if" condition is never met.

What it does state though is :

When a new task is submitted [...], and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle.

Threads will be created as long as the corePoolSize limit is not hit. As long as this limit is not hit, threads will not be reused (but they may die, on uncaught exception, or through the timeout feature of the pool). Which clearly leaves room for the creation of corePoolSize threads, if we create them fast enough or have a long enough queue.

Experimental approach

This knowledge allows us to imagine this scenario : make a fixed pool of size 2, with a waiting queue of size 5, and then submit two long running tasks to the pool. ("Long running" meaning the execution time of each task is one order of magnitude greater than the time it takes for the main thread to submit them, and for the thread pool to ackowledge their presence and work on them). A possible schedule for this is the following :

  1. The main thread submits task T1 to the new, empty, pool
  2. By virtue of the above quote, the corePoolSize not being hit yet, a new thread is created to execute T1.
  3. The thread 1 starts executing T1
  4. The main thread submits T2
  5. As in step 2, a second thread is spawn, and the pool reaches corePoolSize
  6. As in step 3, the second thread starts executing task T2

At this point, the thread pool has en empty queue, and a running thread count of exactly corePoolSize, and not "under corePoolSize", QED.

What it does mean :

Kind of the other way around, it means, the only way to get a number of thread greater than corePoolSize is having allconditions met at the same time :

  1. a number of running threads greater than (or equal to) corePoolSize, and
  2. maximumPoolSize greater than corePoolSize, and
  3. a full queue