当corepoolsize=0且使用linkedblockingqueue时，首个任务直接入队不创建线程；仅当队列offer失败或显式调用prestart方法时才启动线程，因该队列默认无界，offer几乎总成功。
当线程池的 corePoolSize = 0，且使用 LinkedBlockingQueue 作为任务队列时，首个任务不会立即触发新线程创建，而是直接入队；只有当后续任务提交导致队列无法立即接纳（例如队列已满，或使用了带界队列），或调用了 prestartCoreThread() 等显式启动方法，才会真正启动线程——但注意，即便 corePoolSize=0，线程池仍可能运行线程，关键取决于队列容量与任务提交节奏。
corePoolSize=0 的本质含义
它表示线程池**不维护任何常驻核心线程**，即没有“始终存活”的工作线程。但这不等于“永不创建线程”。只要满足以下任一条件，线程仍会被创建：
- 当前运行线程数为 0，且 队列 offer 失败（如使用
ArrayBlockingQueue且已满，或使用SynchronousQueue） - 调用了
prestartAllCoreThreads()或prestartCoreThread() - 设置了
allowCoreThreadTimeOut(true)，且已有线程因空闲超时被回收，后续任务又触发扩容逻辑（但此场景下 corePoolSize=0 时该设置实际无意义）
LinkedBlockingQueue 下首个任务的真实流向
LinkedBlockingQueue 默认是无界队列（容量为 Integer.MAX_VALUE），因此绝大多数情况下 offer(task) 永远成功。此时：
- 提交第一个任务 → 调用
execute()→ 判断workerCount ？→ <code>0 为 false → 进入队列分支 - 执行
workQueue.offer(command)→ 成功返回 true → 不创建新线程 - 此时线程池中 workerCount = 0，所有任务静默堆积在队列中
- 直到有线程被创建并开始从队列中 take 任务——而这个线程通常来自后续某次 submit 触发的扩容，或由
ensurePrestart()机制间接触发（见下一点）
谁来消费队列里的任务？——隐式启动的触发时机
虽然 corePoolSize=0 且队列无界，但线程池并非“永远沉睡”。以下情况会实际拉起第一个工作线程：
-
首次 execute 后，线程池检测到 workerCount == 0 且队列非空：这是关键细节。ThreadPoolExecutor 的
execute()在入队成功后，会再次检查workerCount == 0，若成立则调用addWorker(null, false)尝试添加一个非核心线程（此时core参数为 false） - 该
addWorker调用即使在 corePoolSize=0 下也会成功，因为其准入条件是：workerCount （默认 maximumPoolSize=2147483647），显然满足 - 于是，**第一个任务入队后，线程池自动启动第一个（非核心）线程来消费它**——这正是容易被忽略的隐式行为
对比其他队列类型的行为差异
换用不同队列，行为立刻不同：
- SynchronousQueue：offer 总失败 → 直接走 addWorker 创建线程 → 第一个任务就触发线程启动
- ArrayBlockingQueue(1)：首个任务 offer 成功 → 不启线程；第二个任务 offer 失败 → 启动线程；若此时 workerCount 仍为 0，则新线程启动并消费两个任务（先处理刚提交的，再从队列取第一个）
- DelayedWorkQueue（ScheduledThreadPool）：内部使用堆，offer 一般成功，但调度逻辑独立，不受 corePoolSize=0 的常规路径影响
不复杂但容易忽略：corePoolSize=0 + LinkedBlockingQueue 并非“零线程起步”，而是“零常驻线程 + 首任务后立即派生首个消费线程”。设计时若依赖“绝对无后台线程”，需配合 allowCoreThreadTimeOut(true) 和极小的 maximumPoolSize，或改用手动控制的单线程执行器。
