An executor separates submitting work from running it, but it does not remove capacity decisions. Every executor embodies an admission policy: how many tasks can run, how many can wait, what is rejected, and how shutdown treats outstanding work.
Quick answer
ExecutorService owns task execution and lifecycle. A fixed platform-thread pool limits simultaneous workers; its queue decides how much additional latency and memory the service admits. An unbounded queue can hide overload until latency or memory fails. A rejection policy is part of the API contract, not an exceptional afterthought. Size and validate executors together with CPU, connection pools, deadlines, downstream limits, and user outcomes.
Learning objectives
- Explain how worker count, queue capacity, service time, rejection, and deadlines shape admitted work and latency.
- Build a bounded Java 21 executor lifecycle that makes overload and shutdown outcomes observable.
Prerequisites
Read Java Concurrency for Backend Systems and synchronized, Locks, and Atomic Variables. The Backpressure and Bounded Queues guide provides the system-level model. This lesson belongs to the Java Concurrency course and topic cluster.
Capacity model
For a bounded fixed pool, immediate executor admission is at most active workers plus queue capacity. That is not throughput. Throughput depends on useful service rate and every resource work needs. If eight workers all wait for two database connections, the connection boundary provides at most two concurrent database operations while six workers retain thread capacity.
Queue length is admitted waiting. Queue age is often more actionable: a task can expire before it starts. Rejection can preserve useful work when overload is unavoidable, provided the caller receives a stable retry or failure contract. CallerRunsPolicy can slow a producer, but in an HTTP event loop or latency-sensitive caller it may block the wrong component; choose deliberately.
Java 21 baseline example
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
final class ReportExecutor implements AutoCloseable {
private final ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, 2, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue<>(16),
new ThreadPoolExecutor.AbortPolicy());
void submit(Runnable task) {
executor.execute(task);
}
@Override public void close() {
executor.shutdown();
try {
if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
executor.shutdownNow();
}
} catch (InterruptedException interrupted) {
executor.shutdownNow();
Thread.currentThread().interrupt();
}
}
}The queue and timeout are teaching values, not production recommendations. Production admission must include task size, workload mix, dependency capacity, caller deadlines, and a documented rejection outcome. shutdownNow() attempts interruption; it does not forcibly stop arbitrary code.
Failure scenario: the invisible backlog
A Spring service uses a fixed pool created by a convenience factory with an unbounded queue. A downstream dependency slows from 100 ms to 5 seconds. Active threads stay flat, so the dashboard looks calm, while queued requests grow for minutes. Callers time out, yet stale tasks later execute and repeat expensive work. Memory rises and recovery takes longer than the dependency outage.
The fix combines bounded admission, local expiry before work, end-to-end deadlines, cooperative cancellation, and a clear rejection response. A separate bulkhead protects unrelated traffic. Increasing the pool without measuring the downstream would amplify demand.
Spring execution boundaries
@Async delegates to a configured executor and returns before the work necessarily completes. It does not automatically propagate the caller’s transaction, SecurityContext, MDC, arbitrary ThreadLocal values, or cancellation. Self-invocation and proxy boundaries also matter. Pass the smallest explicit context, configure a named executor, and define how exceptions from void, Future, or CompletableFuture methods become visible.
Virtual threads are different: pooling them to cap count wastes their thread-per-task model. Limit scarce business resources with semaphores, bulkheads, admission control, or the resource owner itself. The next module covers that distinction.
Common misconceptions
- A queue is not free buffering; it consumes memory and deadline budget.
- Maximum pool size may be irrelevant when an unbounded queue prevents growth beyond core workers.
- Rejection is not necessarily a server bug; it can be controlled overload behavior.
- Executor shutdown is not application shutdown unless lifecycle ownership is wired.
- More workers do not add CPU cores, connections, or downstream capacity.
Production validation
Measure submitted, active, queued, oldest queued age, completed, rejected, execution time, and cancellation outcomes. Correlate those with CPU, connection acquisition, dependency saturation, and user latency. Test a slow dependency, a saturated queue, shutdown with outstanding work, and deadline expiry before task start. Use JFR and thread dumps to confirm where workers wait. Keep metrics bounded—task IDs and user IDs belong in protected diagnostics, not metric labels.
Run the Java Concurrency Budget Lab to compare fixed-pool admission with resource guarding. Continue with Java Interruption, Cancellation, and Deadlines.
FAQ
What is the right pool size?
There is no universal formula. Start from workload, service time, CPU, dependency limits, deadlines, and measured contention, then validate under representative load.
Should the queue be unbounded to prevent rejection?
No. That converts immediate overload into unbounded waiting and memory risk. Bounded rejection is often safer and more honest.
Does Future cancellation stop its task?
It may request interruption when supported. The task and every blocking layer must cooperate; arbitrary work is not forcibly terminated.
Related reading
Follow the Java Concurrency learning path, browse the topic, and study Load Shedding and Adaptive Concurrency Limits.
Official sources
- Java SE 21 ExecutorService — accessed August 18, 2026.
- Java SE 21 ThreadPoolExecutor — accessed August 18, 2026.
- Spring Framework task execution — accessed August 18, 2026.