allowcorethreadtimeout是threadpoolexecutor中控制核心线程是否可超时回收的布尔参数，默认false；当设为true且配合setkeepalivetime（>0）使用时，空闲核心线程在超时后会被终止，适用于负载波动大的场景。
allowCoreThreadTimeOut 是什么，什么时候需要它
allowCoreThreadTimeOut 是 ThreadPoolExecutor 的一个布尔开关，控制「核心线程是否也服从 keepAliveTime 闲置回收」。默认是 false，即核心线程一旦创建就一直存活，哪怕长期空闲——这在长周期、稳定负载的场景合理；但如果你的业务有明显波峰波谷（比如每小时批量任务、夜间几乎无请求），核心线程常年挂起反而浪费内存和线程调度开销。
关键点在于：它只对「已启动但当前空闲」的核心线程生效，不影响正在执行任务的线程，也不影响新提交任务时触发的线程创建逻辑。
必须配合 setKeepAliveTime 才能生效
这个参数单独设为 true 没效果。必须同时调用 setKeepAliveTime 设置一个大于 0 的值，否则线程池会忽略超时逻辑。
-
keepAliveTime单位必须明确指定（如TimeUnit.SECONDS），不能只传数字 - 建议最小设为
1秒以上，太小（如 100 毫秒）会导致频繁启停，得不偿失 - 示例：
ThreadPoolExecutor executor = new ThreadPoolExecutor( 4, 8, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(100) ); executor.allowCoreThreadTimeOut(true); // 必须在 setKeepAliveTime 之后或同时设置 executor.setKeepAliveTime(30, TimeUnit.SECONDS);
核心线程被回收的真实条件
不是“一过 keepAliveTime 就杀”，而是满足以下全部条件才会终止空闲核心线程：
allowCoreThreadTimeOut == true- 当前线程处于空闲状态（正阻塞在
workQueue.poll()或类似等待中） - 空闲时长 ≥
keepAliveTime - 线程池未被
shutdown()或shutdownNow() - 当前运行线程数 >
corePoolSize？不，这里容易误解：即使只有 4 个核心线程，只要它们都空闲够久，且allowCoreThreadTimeOut开启，也会逐个被回收，最终可能缩到 0
注意：prestartAllCoreThreads() 启动的线程同样受此机制约束，不是“预启动=永驻”。
常见误判和调试技巧
很多人以为开了 allowCoreThreadTimeOut 就能看到线程数自动跌回 0，结果发现没变化——往往因为：
- 没调用
setKeepAliveTime，或设成了 0 - 线程池里还有任务排队（哪怕只是 1 个），导致至少 1 个线程保持活跃去消费
- 使用了
Executors.newFixedThreadPool()包装器，它内部硬编码allowCoreThreadTimeOut(false)，无法修改 - JVM 退出前没等线程自然回收，直接看 jstack 发现线程还在，其实是还没到超时点
验证是否生效最直接的方式：提交一批任务后静默等待 > keepAliveTime，再用 executor.getActiveCount() 和 executor.getPoolSize() 对比，或通过 JMX 查看 PoolSize 属性变化。
线程回收本身不可见、无回调，别指望日志自动打出“core thread terminated”——得靠主动观测指标。
