Java线程池默认不销毁核心线程以保障响应速度，开启allowCoreThreadTimeOut(true)并满足keepAliveTime>0、队列支持超时poll、线程空闲且池为RUNNING状态时，核心线程才可超时回收。
Java线程池默认把核心线程当作“常驻成员”，哪怕空闲再久也不会销毁——这能保响应速度，但也容易在低谷期白白占着内存和调度资源。要打破这个限制，关键就是开启 allowCoreThreadTimeOut(true)，让核心线程也服从空闲超时回收规则。
核心线程为什么默认不回收
ThreadPoolExecutor 设计上区分核心线程（core threads）和非核心线程（extra threads）。核心线程一旦启动，就长期存活，目的是避免任务来临时反复创建销毁的开销。但这也带来副作用：当业务有明显波峰波谷（比如定时批量任务、夜间静默期），这些“常驻线程”就成了闲置负担。
开启 allowCoreThreadTimeOut 的硬性条件
只调用 allowCoreThreadTimeOut(true) 是不够的，必须同时满足以下三点：
-
keepAliveTime 必须大于 0：设为 0 或负数时，该开关实际无效；建议值如
30L、60L配合TimeUnit.SECONDS -
工作队列需支持超时 poll：例如
SynchronousQueue、DelayedWorkQueue可以，而LinkedBlockingQueue默认不支持阻塞超时（除非显式调用poll(timeout, unit)） - 线程池处于 RUNNING 状态，且线程当前为空闲状态：正在执行任务的线程不受影响，只有阻塞在队列等待中的线程才可能被回收
正确配置写法与常见陷阱
推荐在构造完线程池后立即设置，注意顺序和参数协调：
立即学习“Java免费学习笔记（深入）”；
✅ 正确示例：
ThreadPoolExecutor executor = new ThreadPoolExecutor(<br> 4, // corePoolSize<br> 16, // maxPoolSize<br> 60L, // keepAliveTime > 0<br> TimeUnit.SECONDS,<br> new SynchronousQueue<>() // 支持超时 poll<br>);<br>executor.allowCoreThreadTimeOut(true); // 必须在 setKeepAliveTime 之后或同时生效
❌ 常见错误：
- 用
Executors.newFixedThreadPool(4)—— 它内部硬编码allowCoreThreadTimeOut(false)，无法修改 - 设置了
true却没设keepAliveTime，或设成 0，导致开关形同虚设 - 使用了
LinkedBlockingQueue且未配合自定义逻辑，空闲线程可能一直卡在take()上，不触发超时判断
它真正起作用的时机
不是“一到时间就杀”，而是必须同时满足：
- allowCoreThreadTimeOut == true
- keepAliveTime > 0 且单位明确
- 线程正空闲等待新任务（即从队列
poll(keepAliveTime, unit)返回 null） - 线程池未 shutdown，且当前无排队任务
满足后，空闲核心线程会被中断并退出，线程池规模可缩至 0，实现真正的弹性伸缩。
