Great question—this is a common point of confusion because the surface-level thread creation logic seems to contradict the docs. Let’s unpack why the warning exists by looking at edge cases you might not have considered.

First, let’s recap the docs’ warning #

几乎绝不建议将corePoolSize设为0或启用allowCoreThreadTimeOut，因为这可能导致任务具备执行条件时线程池中无线程处理

Now, the thread creation logic you’re thinking of #

When you submit a new task (like via schedule()), if the current number of threads in the pool is less than corePoolSize, the executor will create a new thread immediately. Even if corePoolSize is 0, submitting a task will trigger a new thread to be created to handle it—so for one-off tasks, this seems to work fine.

The problem arises with delayed/periodic tasks and idle timeouts #

The issue isn’t with the initial task submission—it’s with what happens after threads time out, and there are pending delayed tasks waiting to execute. Here’s a concrete example to illustrate:

• Set corePoolSize = 0, allowCoreThreadTimeOut = true, and keepAliveTime = 5 seconds.
• Submit a scheduleAtFixedRate task that runs every 10 seconds, and each execution takes 1 second.
• The first task triggers a thread to be created. It runs, then the thread waits in the DelayedWorkQueue for the next scheduled run (which is 9 seconds away).
• But the thread’s keep-alive timeout is only 5 seconds. After 5 seconds of idling, the thread shuts down and leaves the pool empty.
• 4 seconds later, the next scheduled task is ready to run (it’s reached its execution time). But there are no threads in the pool to pull it from the queue and execute it.
• This task will sit in the queue until you submit a new task, which triggers a new thread to be created. That thread will then pick up the overdue task and run it—resulting in a delayed execution, or even a missed run if the periodic interval is shorter than the time until a new task is submitted.

Why this doesn’t happen with core threads kept alive #

If you set corePoolSize >= 1 and leave allowCoreThreadTimeOut disabled, the core thread(s) will never time out. They’ll continuously poll the DelayedWorkQueue, and as soon as a task reaches its execution time, the thread will pick it up and run it immediately—no gaps, no missed executions.

The key takeaway #

The docs’ warning is about delayed/periodic tasks that need to execute at specific times, not just one-off tasks. When core threads are allowed to time out or don’t exist at all, there’s no mechanism to wake up a thread to handle an overdue task in the queue. Only a new task submission can trigger thread creation, which leads to unpredictable delays or missed executions for scheduled work.

内容的提问来源于stack exchange，提问作者Passarinho