Core pool size vs maximum pool size in ThreadPoolExecutor

Question

What exactly is the difference between core pool size and maximum pool size when we talk in terms of ThreadPoolExecutor?
C

Answer 1

If you decide to create a ThreadPoolExecutor manually instead of using the Executors factory class, you will need to create and configure one using one of its constructors. The most extensive constructor of this class is:

public ThreadPoolExecutor(
    int corePoolSize,
    int maxPoolSize,
    long keepAlive,
    TimeUnit unit,
    BlockingQueue workQueue,
    RejectedExecutionHandler handler
);

As you can see, you can configure:

• The core pool size (the size the thread pool will try to stick with).
• The maximum pool size.
• The keep alive time, which is a time after which an idle thread is eligible for being torn down.
• The work queue to hold tasks awaiting execution.
• The policy to apply when a task submission is rejected.

Limiting the Number of Queued Tasks

Limiting the number of concurrent tasks being executing, sizing your thread pool, represents a huge benefit for your application and its execution environment in terms of predictability and stability: an unbounded thread creation will eventually exhaust the runtime resources and your application might experience as a consequence, serious performance problems that may lead even to application instability.

That's a solution to just one part of the problem: you're capping the number of tasks being executed but aren't capping the number of jobs that can be submitted and enqueued for later execution. The application will experience resource shortage later, but it will eventually experience it if the submission rate consistently outgrows the execution rate.

The solution to this problem is: Providing a blocking queue to the executor to hold the awaiting tasks. In the case the queue fills up, the submitted task will be "rejected". The RejectedExecutionHandler is invoked when a task submission is rejected, and that's why the verb rejected was quoted in the previous item. You can implement your own rejection policy or use one of the built-in policies provided by the framework.

The default rejection policies has the executor throw a RejectedExecutionException. However, other built-in policies let you:

• Discard a job silently.
• Discard the oldest job and try to resubmit the last one.
• Execute the rejected task on the caller's thread.