This issue is raised when setMaximumPoolSize() is called on a ScheduledThreadPoolExecutor instance.

Why is this an issue?

The ScheduledThreadPoolExecutor class in Java extends ThreadPoolExecutor but has different pool sizing behavior. Unlike the standard ThreadPoolExecutor, which can scale between core and maximum pool sizes based on workload, ScheduledThreadPoolExecutor maintains a fixed number of threads.

Calling setMaximumPoolSize() on a ScheduledThreadPoolExecutor has no effect because this executor type ignores the maximum pool size setting entirely. The pool size is determined solely by the core pool size, which can be set via the constructor or the setCorePoolSize() method.

This behavior exists because scheduled tasks require predictable thread allocation. The executor needs to maintain a consistent number of threads to handle recurring and delayed tasks reliably.

Since setMaximumPoolSize() is always silently ignored by ScheduledThreadPoolExecutor, this call is never intentional and can safely be removed or replaced.

What is the potential impact?

Calling setMaximumPoolSize() on a ScheduledThreadPoolExecutor creates misleading code that suggests dynamic scaling behavior that doesn’t actually occur. This can lead to:

• Performance issues: Developers may assume the pool will scale up under load, but it won’t, potentially causing task queuing and delays.
• Resource misallocation: The actual thread count differs from what the code suggests, making capacity planning difficult.
• Maintenance problems: Future developers may be confused by the ineffective method call and waste time debugging.

How to fix it

Remove the call to setMaximumPoolSize() and use setCorePoolSize() instead to control the number of threads in the pool.

Note that ScheduledThreadPoolExecutor does not scale dynamically like ThreadPoolExecutor. The pool maintains a fixed number of threads equal to the core pool size. You must determine the required number of threads upfront based on your expected concurrent task load.

If you originally intended the pool to scale from 5 to 10 threads under load, you now need to choose a fixed size (such as 10) that can handle your peak workload.

Code examples

Noncompliant code example

ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(5);
executor.scheduleAtFixedRate(task1, 0, 1, TimeUnit.SECONDS);
executor.scheduleAtFixedRate(task2, 0, 5, TimeUnit.SECONDS);
// Try to allow more concurrent threads
executor.setMaximumPoolSize(10); // Noncompliant

Compliant solution

ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(5);
executor.scheduleAtFixedRate(task1, 0, 1, TimeUnit.SECONDS);
executor.scheduleAtFixedRate(task2, 0, 5, TimeUnit.SECONDS);
// Allow more concurrent threads
executor.setCorePoolSize(10); // Pool now maintains exactly 10 threads

Resources

Documentation

• Java Documentation - ScheduledThreadPoolExecutor (Java SE 17)