核心线程不被销毁是因为getTask()对核心线程调用无超时的take()使其在条件变量上挂起等待，而非轮询；非核心线程则通过带超时的poll()在空闲超时后退出。

核心线程不被销毁，关键就在 getTask() 方法的阻塞逻辑里——它不是靠“一直轮询”，而是让线程在队列上真正挂起等待，从而既省资源又保存活。

getTask 的核心作用：决定线程要不要继续干活

每个工作线程（Worker）启动后，最终都会进入 runWorker 循环，反复调用 getTask() 去取任务。这个方法不是简单地“查一下有没有任务”，而是根据线程身份（核心 or 非核心）和配置，选择不同的等待方式：

• 如果当前是核心线程（wc ≤ corePoolSize 且 allowCoreThreadTimeOut == false），默认走 workQueue.take() —— 这是无超时的阻塞调用，线程会一直停在队列的条件变量上，直到有新任务入队才被唤醒
• 如果当前是非核心线程（wc > corePoolSize 或 allowCoreThreadTimeOut == true），则走 workQueue.poll(keepAliveTime, unit) —— 超时后返回 null，触发线程退出流程

阻塞背后的机制：take() 是怎么锁住线程的

take() 在典型实现如 LinkedBlockingQueue 中，本质是：

• 先获取 notEmpty 条件队列的锁
• 检查队列是否为空；为空就调用 notEmpty.await()，把当前线程加入等待队列并释放锁
• 线程状态变为 WAITING，彻底交出 CPU，不消耗任何计算资源
• 当其他线程调用 put() 或 offer() 并成功入队后，会触发 notEmpty.signal()，唤醒一个等待线程

也就是说，核心线程不是“空转耗电”，而是被操作系统级的线程调度器挂起，完全静默待命。

为什么 allowCoreThreadTimeOut 默认 false 就能保住核心线程

这个布尔值直接参与 timed 变量的计算：
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;

• 默认为 false，那么只要线程数 ≤ corePoolSize，timed 就是 false
• 进而跳过超时分支，强制进入 take() 分支
• 哪怕队列连续空闲几小时，线程也始终处于 await 状态，不会因超时返回 null，也就不会走到 processWorkerExit

实战中可验证的关键点

你可以在调试时重点关注这几个行为：

• 提交少量任务后观察线程 dump：核心线程状态应为 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
• 把 allowCoreThreadTimeOut 设为 true 再试：即使只有核心线程，空闲 keepAliveTime 后也会退出
• 往满队列持续提交任务：非核心线程会在 poll 超时后陆续消退，而核心线程数量稳定不变