非核心线程回收本质是主动退出：空闲时调用workQueue.poll(keepAliveTime, unit)，超时返回null导致runWorker循环终止，线程自然结束；需keepAliveTime>0且线程池处于RUNNING状态。
Java 线程池中，非核心线程在空闲时被回收，本质是线程主动退出运行循环，而非被外部“杀死”。关键在于它从任务队列取任务的方式和超时机制。
非核心线程回收的触发条件
非核心线程指数量超过 corePoolSize 但未超过 maximumPoolSize 的那部分线程。它的回收只发生在以下同时满足时：
- 线程当前处于空闲状态（已完成上一个任务，正等待下一个任务）
- 线程池仍处于 RUNNING 状态（未调用 shutdown/shutdownNow）
- 当前总线程数 > corePoolSize（即该线程确实被判定为“非核心”）
- 空闲时间超过 keepAliveTime 设置的阈值
回收是如何发生的：getTask() 返回 null
每个工作线程都运行在 runWorker 循环中，持续调用 getTask() 获取新任务。一旦 getTask() 返回 null，循环退出，线程自然终止，其持有的资源（包括 ThreadLocalMap、栈变量等）随线程对象被 JVM 回收。
对非核心线程，getTask() 内部使用的是：
立即学习“Java免费学习笔记（深入）”；
- workQueue.poll(keepAliveTime, unit) —— 带超时的非阻塞获取
- 若在 keepAliveTime 内队列为空，poll 返回 null，线程退出
这与核心线程默认使用的 workQueue.take()（无限阻塞）形成关键区别。
资源释放的关键细节
线程终止本身会释放其独占资源，但要注意两类常见误区：
- ThreadLocal 不会自动清理：只要线程还活着，它持有的 ThreadLocal 值就可能长期驻留。keepAliveTime 缩短了线程寿命，降低了泄漏风险窗口，但不能替代 threadLocal.remove()。必须在业务逻辑结束前显式调用，尤其在 finally 块中
- 工作队列类型影响行为：SynchronousQueue、DelayedWorkQueue 支持超时 poll；而 LinkedBlockingQueue 的 poll(timeout) 不会阻塞，超时前队列为空就直接返回 null，实际空闲等待效果可能弱于预期
确保回收生效的配置要点
要让非核心线程真正“及时退场”，需确认以下设置：
- keepAliveTime 明确设置为正数值（如 10L、30L），单位匹配 TimeUnit
- 线程池未被 shutdown 或 shutdownNow —— 这些操作会强制所有线程尽快退出，不走 keepAliveTime 流程
- 避免将 keepAliveTime 设为 0 或负数，否则可能触发立即回收逻辑，行为依赖具体队列实现，不够稳定
- 若需更激进缩容（例如低峰期清空全部线程），可配合 allowCoreThreadTimeOut(true)，使核心线程也走 poll 超时逻辑
