Thread pools often require dynamic parameter adjustments as business workloads fluctuate. A fixed configuration may work initially but eventually leads to saturated queues and rejected tasks. One common monitoring strategy triggers alerts when queue usage exceeds 80%, prompting engineers to adjust parameters via a management dashboard.

The standard ThreadPoolExecutor provides setters for corePoolSize and maximumPoolSize, but queue capacity is typically final in implementations like LinkedBlockingQueue. To enable dynamic resizing, a custom queue implementation is necessary.

Below is an example of a dynamical adjustable thread pool setup:

import java.util.concurrent.*;

public class DynamicPoolDemo {

    public static void main(String[] args) {
        runPoolAdjustment();
    }

    private static ThreadPoolExecutor createPool() {
        return new ThreadPoolExecutor(
                2,
                5,
                30,
                TimeUnit.SECONDS,
                new FlexibleQueue<>(10),
                new CustomThreadFactory("worker")
        );
    }

    private static void runPoolAdjustment() {
        ThreadPoolExecutor pool = createPool();

        for (int i = 0; i < 15; i++) {
            pool.execute(() -> {
                printPoolMetrics(pool, "Task submitted");
                try {
                    TimeUnit.SECONDS.sleep(4);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        printPoolMetrics(pool, "Before adjustment");
        pool.setCorePoolSize(10);
        pool.setMaximumPoolSize(10);

        FlexibleQueue<Runnable> flexibleQueue = (FlexibleQueue<Runnable>) pool.getQueue();
        flexibleQueue.resize(100);

        printPoolMetrics(pool, "After adjustment");
    }

    private static void printPoolMetrics(ThreadPoolExecutor pool, String tag) {
        BlockingQueue<Runnable> q = pool.getQueue();
        int totalCapacity = q.size() + q.remainingCapacity();
        System.out.printf(
                "[%s] %s -> Core: %d, Active: %d, Max: %d, Usage: %.2f%%, Queue: %d/%d%n",
                Thread.currentThread().getName(),
                tag,
                pool.getCorePoolSize(),
                pool.getActiveCount(),
                pool.getMaximumPoolSize(),
                pool.getActiveCount() * 100.0 / pool.getMaximumPoolSize(),
                q.size(),
                totalCapacity
        );
    }

    static class CustomThreadFactory implements ThreadFactory {
        private final String prefix;
        private int counter = 0;

        CustomThreadFactory(String prefix) {
            this.prefix = prefix;
        }

        public Thread newThread(Runnable r) {
            return new Thread(r, prefix + "-" + counter++);
        }
    }
}

The FlexibleQueue is a modified version of LinkedBlockingQueue where the capacity field is no longer final and includes a resize() method.

The naive implementation of resize() only updates the field:

public void resize(int newCapacity) {
    this.capacity = newCapacity;
}

This creates a problem. In LinkedBlockingQueue, methods like put() block when the queue is full:

while (count.get() == capacity) {
    notFull.await();
}

If a producer thread is blocked because the queue is full and another thread calls resize() to increase capacity, the blocked thread remains asleep unless explicitly signaled.

A correct resize() implementation must wake waiting producers when capacity increases:

public void resize(int newCapacity) {
    int oldCapacity = this.capacity;
    this.capacity = newCapacity;
    int currentSize = count.get();

    if (newCapacity > oldCapacity && currentSize >= oldCapacity) {
        signalNotFull();
    }
}

This ensures that threads blocked on a full queue are notified as soon as additional space becomes available.

Note that ThreadPoolExecutor uses offer() instead of put() when adding tasks to the queue. Since offer() does not block, the above scenario is less likely in standard pool usage. However, if custom code or extensions (such as certain MQ-inspired queue implementations) use put(), the signaling logic becomes critical.

A separate concurrency issue arises when setCorePoolSize() races with task submission. If setCorePoolSize() adds a worker that is registered in the workers set but not yet started, there is a brief window where the pool appears fully utilized. During this window, a task submission may see a full queue and no available threads, resulting in a RejectedExecutionException, even though the total capacity has not been exceeded.

This race condition is intermittent and difficult to reproduce, but it is a known edge case when dynamically adjusting core pool size under load.

The JDK maintainers have historically avoided making LinkedBlockingQueue resizable, citing the complexity and risk of introducing concurrency bugs. For production systems, a carefully implemented custom queue with proper signaling remains the recommended approach.