核心线程数采用懒加载机制，即任务提交时按需创建，直到达到corepoolsize；判断逻辑为：当前线程数＜corepoolsize则新建核心线程，否则入队，队列满且总线程数＜maximumpoolsize才建非核心线程。

核心线程数不是一启动就全创建好的，而是“按需上岗”——有任务来了才逐步创建，直到达到设定值。图解的关键，是抓住「任务提交」和「当前线程数」这两个变量的实时对比关系。

懒加载的触发条件：三步判断逻辑

每次提交任务时，线程池内部会按固定顺序做判断：

• 若当前运行线程数 ＜ corePoolSize → 立即新建一个核心线程执行该任务（哪怕已有空闲线程）
• 若当前运行线程数 ≥ corePoolSize → 不再新建核心线程，转而尝试把任务加进工作队列
• 若队列已满且总线程数 ＜ maximumPoolSize → 才考虑创建非核心线程

图解典型场景：从0到corePoolSize的线程增长过程

假设 corePoolSize = 3，初始线程数为0：

• 第1个任务到达 → 当前线程数0＜3 → 创建第1个核心线程（T1）
• 第2个任务到达 → 当前线程数1＜3 → 创建第2个核心线程（T2）
• 第3个任务到达 → 当前线程数2＜3 → 创建第3个核心线程（T3）
• 第4个任务到达 → 当前线程数3＝3 → 不创建新线程，任务入队等待
• 后续任务持续到来 → 只要队列未满，始终复用T1/T2/T3，不再新增核心线程

注意两个易被忽略的事实

懒加载不是“延迟加载”，而是“条件驱动”：

• 不调用 prestartCoreThread() 或 prestartAllCoreThreads()，线程池绝不会主动创建任何核心线程
• 即使队列里已堆积100个任务，只要当前线程数还没到corePoolSize，仍会继续创建核心线程（而非优先让现有线程消费队列）

什么情况下懒加载“看起来没生效”？

常见误解是“提交任务后线程没立刻起来”，其实可能因为：

• 任务提交太快，线程刚创建完就进入RUNNABLE状态，监控工具抓取不到创建瞬间
• 使用了无界队列（如LinkedBlockingQueue默认容量Integer.MAX_VALUE），导致队列几乎永不“满”，从而长期卡在“入队”分支，核心线程数始终停留在较低水平
• 线程工厂（ThreadFactory）中设置了自定义命名或优先级，掩盖了线程实际已创建的事实