keepalivetime仅作用于超出corepoolsize的非核心线程，需满足线程数＞corepoolsize、线程处于timed_waiting状态且线程池未shutdown；配合有界队列、合理maxpoolsize及allowcorethreadtimeout才能实现弹性缩容。

KeepAliveTime 不是“设了就起作用”的开关，而是线程池弹性回收的节拍器——它只对超出核心线程数的非核心线程生效，且必须配合队列策略、最大线程数和业务节奏协同工作，才能真正压降内存、句柄和调度开销。

keepAliveTime 管谁？什么时候才真正回收？

它不控制所有线程，只影响那些“多出来的”非核心线程：

• 前提是当前线程数 > corePoolSize，比如 core=4、max=12，当负载回落到 7 个线程时，那额外的 3 个才进入倒计时
• 线程必须处于 TIMED_WAITING 状态（例如在队列上阻塞等待任务超时），不是“看起来没活干”就算空闲
• 线程池不能处于 shutdown 状态；否则 keepAliveTime 归零失效
• 若用的是无界队列（如 new LinkedBlockingQueue()），任务永不排队满，非核心线程根本不会创建，keepAliveTime 就完全没机会触发

按业务类型选值：不是越短越好，也不是越长越稳

关键看任务卡在哪、流量怎么波动：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• IO 密集型（HTTP 调用、DB 查询）：建议 60–180 秒。留出时间复用连接上下文，避免频繁重连带来的 socket 创建/销毁开销
• 计算密集型（批量解析、加解密）：建议 10–60 秒。CPU 时间片宝贵，空闲即释放，减少上下文切换损耗
• 秒杀类脉冲负载：设为 30–60 秒。覆盖典型退潮期，既避免线程刚建好就销毁，又防止低峰期大量线程长期占位
• 设为 0L：非核心线程一空闲立刻销毁。适合极短突发（如每小时一次定时上报），后续几小时完全无请求的场景

想让核心线程也缩容？必须配对开启 allowCoreThreadTimeOut

单独调小 keepAliveTime 对核心线程无效。要实现“高峰扩容、退潮归零”，两步缺一不可：

• 显式调用 executor.allowCoreThreadTimeOut(true)
• 同时设置合理的 keepAliveTime（如 60 秒），此时所有空闲线程（含 corePoolSize 内的）都会受控
• 注意：该配置仅对手动构建的 ThreadPoolExecutor 生效，Executors.newFixedThreadPool() 或 newCachedThreadPool() 均不支持
• 上线后务必验证：观察 getPoolSize() 是否能回落到 0 或接近 0，而不是卡在 corePoolSize 不动

配套必须检查的三项配置

keepAliveTime 的效果高度依赖整体设计：

• workQueue 必须有界：用 ArrayBlockingQueue 或带容量的 LinkedBlockingQueue（如 new LinkedBlockingQueue(100)）。无界队列会让扩容机制失效，非核心线程永不创建
• maximumPoolSize 要留余量：至少为核心线程数的 1.5–3 倍（IO 密集型可更高），否则即使 keepAliveTime 合理，也没法扩出新线程应对高峰
• 拒绝策略建议 CallerRunsPolicy：当队列满 + 线程达上限时，由提交线程自己执行任务，既限流又反压，避免雪崩或任务丢失

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南