Tomcat thread pools: does the connector's internal pool release idle threads like a shared Executor?

Direct Answer

The Tomcat 9/10 NIO connector's internal thread pool does not shrink down to zero after idle periods. It maintains at least minSpareThreads threads alive indefinitely. Only threads beyond that threshold are eligible for termination after the executor's keepAliveTime (default 60 seconds when using a shared Executor).

Confirmed Behavior vs. Shared Executor

• Internal pool: Uses ThreadPoolExecutor where corePoolSize = minSpareThreads and allowCoreThreadTimeOut = false by default. Core threads never expire.
• Shared Executor: Explicitly documents maxIdleTime for idle-thread termination. When configured, it applies to all threads above minSpareThreads.

Key Implications

1. Memory floor: Your memory footprint cannot drop below minSpareThreads × thread_stack_size. With default minSpareThreads=10 and typical 1MB stack, that's ~10MB reserved even during total idle.
2. Latency tradeoff: Setting minSpareThreads too low (e.g., 1-2) risks latency spikes after idle as new core threads are spawned for incoming requests.
3. Tuning path: To reduce footprint, lower minSpareThreads and optionally configure a shared Executor with a shorter maxIdleTime for more aggressive reaping of excess threads.

Verification Steps

# After a burst, check thread count drops to minSpareThreads only
jstack <pid> | grep 'http-nio' | wc -l

# Confirm connector uses internal pool (no shared Executor configured)
cat $CATALINA_HOME/conf/server.xml | grep -A5 'Connector.*HTTP'

Recommended Configuration

For low-traffic deployments, set:

• minSpareThreads=4 (minimum practical floor to avoid latency)
• maxThreads=50 (sufficient for bursts)
• Optionally add a shared Executor with maxIdleTime=30000 for faster cleanup

Open Question

What is your peak concurrent request count during traffic bursts? This determines the safe upper bound for maxThreads and whether the default 200 is overkill for your workload.