Doc: ThreadPoolTaskExecutor's defaults vs setting queueCapacity for common pool scenarios [SPR-16944]

[spring-projects-issues]

Constantino Cronemberger opened SPR-16944 and commented

According to ThreadPoolExecutor Javadoc:

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

In the class ThreadPoolTaskExecutor the default values are: 1 for the corePoolSize and Integer.MAX_VALUE for maxPoolSize and queueCapacity.

This means that a second thread will be created only when we have MAX_VALUE elements in the queue. This is is not reasonable.

I think queueCapacity should not have a default value.

---

Issue Links:

• Doc: AsyncConfigurer causes dependencies to be created early [SPR-16945] #21484 Doc: AsyncConfigurer causes dependencies to be created early

Backported to: 4.3.19

[spring-projects-issues]

Juergen Hoeller commented

Those defaults essentially mimic Executors.newFixedThreadPool(1) / Executors.newSingleThreadExecutor(), sharing a single pooled thread for all tasks. The unbounded maxPoolSize may appear odd here (since it is behaviorally equivalent to a maximum of 1); that setting is primarily there in case of a custom queueCapacity, providing scaling by default at that point (without setting a custom maxPoolSize at the same time).

Making the default queueCapacity 0 and therefore not allowing for any queued tasks would mimic Executors.newCachedThreadPool(), with immediate scaling of threads in the pool to a potentially very high number. While this is not unreasonable in many scenarios, the fixed single thread seems to be safer default. As outlined above, enabling this mode of operation just requires setting queueCapacity to 0, without touching the maxPoolSize setting.

I'll therefore turn this into a documentation task, making those typical scenarios clearer.