java线程池需显式启用allowcorethreadtimeout(true)并设置keepalivetime>0，且仅threadpoolexecutor有效，核心线程空闲超时后可回收至0，新任务仍按需创建。
Java 线程池默认不销毁核心线程，哪怕长期空闲；要让它们也能超时回收，必须显式启用 allowCoreThreadTimeOut(true)，并配合有效的 keepAliveTime 设置——否则该开关完全无效。
核心线程回收的前提条件
核心线程不是“设了就回收”，它生效需要同时满足三个硬性条件：
-
keepAliveTime 必须大于 0（单位明确，如
TimeUnit.SECONDS），设为 0 或未设置，allowCoreThreadTimeOut不起作用 -
线程池类型必须是 ThreadPoolExecutor 或其子类：通过
Executors.newFixedThreadPool()等工具方法创建的线程池无法启用该功能（前者固定大小且禁止超时，后者 corePoolSize=0） -
核心线程必须处于空闲阻塞状态：即已执行完任务、正在调用
workQueue.poll(keepAliveTime, unit)等待新任务，且等待时间 ≥ keepAliveTime
回收行为的实际表现
开启后，核心线程不再“终身雇佣”，而是和非核心线程一样受空闲存活策略约束：
- 所有空闲线程（无论核心与否）都使用
poll()超时等待，超时返回null后自动退出循环、终止运行 - 线程数可真正缩容至 0（例如
corePoolSize=2，但连续空闲 30 秒后两个线程都被回收） - 新任务到来时，仍会按需新建核心线程（只要线程池未 shutdown），实现“按需伸缩”
-
prestartAllCoreThreads()预启动的线程也受此规则约束，不是“预启即永驻”
配置要点与避坑建议
想让核心线程回收真正落地，关键在参数搭配和场景匹配：
-
keepAliveTime 推荐设为秒级或分钟级，如
30L, TimeUnit.SECONDS；避免设成毫秒级（如 100ms），否则频繁启停反而增加调度开销 - 适合负载波峰波谷明显的场景：比如定时批量任务、夜间低流量服务、嵌入式或容器化环境（对线程数/内存敏感）
- 高吞吐、持续高并发场景慎用：频繁销毁重建核心线程会抵消资源节省收益，甚至拖慢响应
-
必须手动构建 ThreadPoolExecutor，并在构造后立即调用
allowCoreThreadTimeOut(true)和setKeepAliveTime(...)
回收的本质是 getTask() 返回 null
线程池不“主动杀线程”，而是靠 Worker 内部循环逻辑自然退出：
- 每个 Worker 线程执行
runWorker()，不断调用getTask()获取任务 - 当
allowCoreThreadTimeOut=true且当前空闲时间达标，getTask()对核心线程也走poll()分支，超时即返回null - 循环结束 → 执行
processWorkerExit()清理 → 线程终止
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
