默认情况下核心线程长期闲置也不回收，这是由源码硬性保障的设计红线：1.核心线程用workqueue.take()无限阻塞，非核心线程才用poll(timeout)；2.processworkerexit()中allowcorethreadtimeout=false时，线程数≥corepoolsize即直接返回，不销毁；3.只要线程池处于running状态，ctl机制就绑定核心线程与池生命周期。
默认情况下，核心线程长期闲置也不回收，这不是一个“可选行为”，而是线程池设计中一条明确的物理红线——它由源码逻辑硬性保障，不依赖配置、不随负载波动、不受超时参数干扰。
这条红线体现在三个硬性机制上
1. 阻塞方式不同：核心线程永远用 take()，非核心线程才用 poll(timeout)
核心线程执行任务循环时，调用的是 workQueue.take()，这是一个无时限阻塞操作，线程会一直卡在队列头部等待，不会因空闲而退出。而非核心线程调用的是 workQueue.poll(keepAliveTime, unit)，超时即返回 null，触发销毁流程。
2. 销毁入口被条件拦截：processWorkerExit() 中有显式守门逻辑
当一个 Worker 退出时，会进入 processWorkerExit() 方法。其中关键判断是：
- 若
allowCoreThreadTimeOut == false（默认值），则min = corePoolSize - 只要当前线程数 ≥
corePoolSize，就直接 return，不再补新线程，也不允许该 Worker 被当作“可销毁对象”处理 - 只有当
workerCount 时，才会调用 <code>addWorker(null, false)尝试补充——这本身就说明：系统认定“少于 corePoolSize 的数量是不可接受的下限”
3. ctl 状态位与生命周期绑定：核心线程的存续直接受运行状态控制
线程池通过一个 AtomicInteger ctl 同时管理运行状态和线程数。核心线程只有在 shutdown() 或 shutdownNow() 调用后，使运行状态变为 SHUTDOWN 或 STOP，才会被批量中断或强制终止。只要池处于 RUNNING 状态，核心线程的生命周期就与池本身一致——它不是“某个线程自己决定退休”，而是“池不允许它退休”。
为什么必须设为红线？不是为了省那点创建开销
表面看是避免重复创建/销毁，深层原因是保障响应确定性：
- 新任务到达时，若核心线程已全部回收，就得重新创建——哪怕只多花几毫秒，也会破坏高并发场景下的毛刺控制
- 核心线程常驻，意味着任务从提交到执行的路径最短（无需排队、无需扩容判断），这是 SLA 可预测性的底层支撑
- 动态扩缩容针对的是突增流量，而核心线程代表的是业务的“基线吞吐能力”，基线一旦动摇，整个弹性策略就失去锚点
可以打破红线吗？可以，但代价清晰
调用 allowCoreThreadTimeOut(true) 确实能让核心线程也遵守 keepAliveTime，但这不是“优化”，而是主动放弃基线保障：
- 线程池可能缩容至 0，下次任务来临时需重建全部核心线程，延迟陡增
- 在低频但要求快速响应的场景（如定时调度、后台心跳），反而更容易出现冷启动抖动
- 除非你明确接受“空闲即归零”的语义（例如函数计算类短生命周期服务），否则生产环境极少启用
