KeepAliveTime仅作用于超出corePoolSize的非核心线程，需满足线程数＞corePoolSize、线程处于TIMED_WAITING状态且线程池未shutdown；配合有界队列、合理maxPoolSize及allowCoreThreadTimeOut才能实现弹性缩容。
KeepAliveTime 不是“设了就起作用”的开关，而是线程池弹性回收的节拍器——它只对超出核心线程数的非核心线程生效，且必须配合队列策略、最大线程数和业务节奏协同工作，才能真正压降内存、句柄和调度开销。
keepAliveTime 管谁？什么时候才真正回收？
它不控制所有线程，只影响那些“多出来的”非核心线程：
- 前提是当前线程数 > corePoolSize，比如 core=4、max=12，当负载回落到 7 个线程时，那额外的 3 个才进入倒计时
- 线程必须处于 TIMED_WAITING 状态（例如在队列上阻塞等待任务超时），不是“看起来没活干”就算空闲
- 线程池不能处于 shutdown 状态；否则 keepAliveTime 归零失效
- 若用的是无界队列（如 new LinkedBlockingQueue()），任务永不排队满，非核心线程根本不会创建，keepAliveTime 就完全没机会触发
按业务类型选值：不是越短越好，也不是越长越稳
关键看任务卡在哪、流量怎么波动：
- IO 密集型（HTTP 调用、DB 查询）：建议 60–180 秒。留出时间复用连接上下文，避免频繁重连带来的 socket 创建/销毁开销
- 计算密集型（批量解析、加解密）：建议 10–60 秒。CPU 时间片宝贵，空闲即释放，减少上下文切换损耗
- 秒杀类脉冲负载：设为 30–60 秒。覆盖典型退潮期，既避免线程刚建好就销毁，又防止低峰期大量线程长期占位
- 设为 0L：非核心线程一空闲立刻销毁。适合极短突发（如每小时一次定时上报），后续几小时完全无请求的场景
想让核心线程也缩容？必须配对开启 allowCoreThreadTimeOut
单独调小 keepAliveTime 对核心线程无效。要实现“高峰扩容、退潮归零”，两步缺一不可：
立即学习“Java免费学习笔记（深入）”；
- 显式调用 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：当队列满 + 线程达上限时，由提交线程自己执行任务，既限流又反压，避免雪崩或任务丢失
