核心线程不超时退出是因为getTask()中timed=false时调用workQueue.take()无限阻塞；非核心线程timed=true，超时后退出；shutdown或shutdownNow会强制中断守候。
线程池中核心线程的“守候机制”，本质是 getTask() 方法在任务空闲时的阻塞行为——它让核心线程不退出、不销毁，持续等待新任务。这种守候不是靠轮询或忙等，而是依托阻塞队列的 take() 调用实现的轻量级挂起。
核心线程为何不超时退出
关键在 getTask() 中的 timed 判断逻辑：
- 当工作线程数 ≤
corePoolSize，且allowCoreThreadTimeOut == false（默认值）时，timed = false - 此时线程调用的是
workQueue.take()，而非带超时的poll() -
take()会无限期阻塞，直到队列有任务入队才被唤醒并返回，线程始终保持存活
非核心线程如何体现“救急后撤离”
非核心线程（即 workerCount > corePoolSize 的线程）的行为正好相反：
- 其
timed = true，触发workQueue.poll(keepAliveTime, NANOSECONDS) - 若在
keepAliveTime内未取到任务，timedOut = true，下一轮循环将满足退出条件 - 只要队列为空且线程数 > 1，或当前线程是最后一个但队列仍空，就会执行
decrementWorkerCount()并返回null，最终被processWorkerExit清理
线程池状态变化如何强制中断守候
即使核心线程正在 take() 阻塞，以下两种状态变更也会立即终止守候：
-
调用
shutdown()：线程池进入SHUTDOWN状态，后续若发现workQueue.isEmpty()，getTask()直接返回null，线程开始退出流程 -
调用
shutdownNow()：状态升至STOP，所有阻塞中的take()或poll()会被InterruptedException中断，线程捕获异常后重置timedOut = false，但外层状态校验失败，仍返回null
实战调试建议：观察守候行为的关键点
可在本地复现并验证该机制：
- 构造一个
corePoolSize=2、maximumPoolSize=4、keepAliveTime=10s、使用ArrayBlockingQueue(5)的线程池 - 提交 2 个长期休眠任务（如
Thread.sleep(60_000)），此时仅启用 2 个核心线程，它们将卡在take()上 - 再提交第 3 个任务：触发创建第 3 个线程（非核心），它执行完后将在 10 秒无任务时自动退出
- 用 JStack 查看线程栈，可清晰看到核心线程处于
parking to wait for [java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject]，即阻塞在队列的条件等待上
