keepAliveTime仅控制非核心线程空闲超时后的终止，不影响局部变量等资源回收；它影响ThreadLocal和外部资源释放，需手动清理；开启allowCoreThreadTimeOut后核心线程也受其约束。
keepAliveTime 不直接影响变量资源的回收，它只控制线程对象本身的生命周期。变量（如局部变量、方法参数、临时对象）的生命周期由 JVM 的栈帧和垃圾回收机制决定，与线程是否被回收无关；而 keepAliveTime 决定的是：当一个非核心线程空闲多久后，线程池主动终止该线程实例。
keepAliveTime 管什么、不管什么
它只作用于线程池中“超出 corePoolSize 的那部分线程”——也就是非核心线程。这些线程在空闲状态持续超过 keepAliveTime 后，会被线程池调用 interrupt() 并退出执行循环，最终被 JVM 回收线程对象本身。
- ✅ 管：非核心线程的存活时长、是否被 shutdown、是否释放其持有的线程栈内存（如 ThreadLocal 变量若未清理，可能引发内存泄漏）
- ❌ 不管：方法内定义的局部变量、new 出的对象、静态变量、数据库连接等——这些由 GC 或显式 close 控制
真正影响变量资源回收的关键点
keepAliveTime 间接影响两类资源：ThreadLocal 和未关闭的外部资源（如文件句柄、Socket）。因为线程终止时，若未主动清理，这些资源不会自动释放。
- ThreadLocal：每个线程持有独立副本，线程结束时不会自动清空。若 keepAliveTime 过长且线程复用频繁，又没调用
remove()，容易导致内存堆积 - 外部资源：比如在线程中打开 FileInputStream 却没在 finally 中 close，线程长期存活会持续占用文件句柄；线程被回收后句柄才可能释放（取决于 JVM 实现），但不可依赖
- 建议在线程任务结束前统一清理：显式 remove ThreadLocal、close 流、释放锁、归还连接池连接
allowCoreThreadTimeOut 改变行为边界
默认情况下，核心线程永不超时；一旦开启 allowCoreThreadTimeOut(true)，keepAliveTime 就对所有空闲线程生效——包括 corePoolSize 内的线程。
- 开启后，整个线程池更“弹性”，低峰期可缩容至 0 线程（若无任务），降低资源驻留压力
- 但要注意：线程销毁 + 新建有开销，高并发突增时响应延迟可能上升
- 适合流量波动大、对资源敏感的场景（如云函数后台任务池）
配置建议：结合业务节奏设值
keepAliveTime 不是越短越好，也不是越长越稳，需匹配典型空闲窗口。
- 高频短任务（如 API 网关请求）：设为 10~30 秒。避免线程频繁启停，也防止低谷期冗余驻留
- 低频长任务（如定时报表生成）：可设为 5~10 分钟。减少重建开销，尤其当任务启动成本高（如加载大模型上下文）
- 极端情况（如突发秒杀后快速回落）：配合动态调参（如通过 Actuator 暴露端点调整），比固定值更有效
