keepalivetime决定非核心线程空闲超时回收时间，仅在线程数＞corepoolsize时生效；设为true可使核心线程也受其约束；单位需匹配业务节奏，配合有界队列才能触发扩容与收缩。
keepAliveTime 是线程池实现弹性伸缩的关键开关，它不控制“要不要扩容”，而是决定“扩出来的线程何时该缩回去”。真正起效的前提是：线程数已超过 corePoolSize，且这些多出来的线程进入了空闲状态。
keepAliveTime 只作用于非核心线程
默认情况下，只有线程数 > corePoolSize 时创建的线程才受 keepAliveTime 约束。例如配置 core=2，max=6，keepAliveTime=30s，意味着：最多可临时增加 4 个非核心线程；一旦某非核心线程连续 30 秒没拿到任务，就会被自动终止，线程数回落至 ≤2。
若想让核心线程也参与回收，必须显式调用：
- executor.allowCoreThreadTimeOut(true)
此时所有线程（包括最初那 2 个）都遵循 keepAliveTime 规则，空闲超时即销毁——线程数可降至 0，彻底释放资源。
单位与数值选择直接影响伸缩灵敏度
keepAliveTime 的单位（TimeUnit）必须和业务波动节奏匹配。短周期突发流量适合毫秒级设置，长尾型服务更适合秒级或分钟级：
- 高频短任务（如 API 网关鉴权）：设为 100–500ms，快速释放冗余线程，避免堆积
- 中低频批处理（如定时报表生成）：设为 30–120s，平衡创建开销与资源占用
- 极低频后台任务（如日志归档）：可设为 5–10 分钟，减少反复启停损耗
注意：单位写错是常见陷阱。传入 60 却用 TimeUnit.MILLISECONDS，等于只留 60 毫秒——线程几乎刚建完就销毁。
配合有界队列才能触发真正的弹性行为
keepAliveTime 要生效，前提是线程池确实“扩过容”。而扩容动作只在 workQueue 已满 + 当前线程数 时发生。
因此，使用无界队列（如 LinkedBlockingQueue 不设容量）会导致线程数永远卡在 corePoolSize，keepAliveTime 形同虚设。
- 推荐用 ArrayBlockingQueue(200) 或 LinkedBlockingQueue(1000) 这类有界队列
- 队列容量需结合平均任务耗时与峰值 QPS 估算，避免过小导致频繁扩容、过大导致扩容失效
监控与动态调优建议
生产环境不能只靠静态配置。可通过以下方式闭环管理：
- 暴露 getPoolSize()、getActiveCount()、getCompletedTaskCount() 等指标，接入 Prometheus
- 观察“线程数峰值→回落时间”是否接近 keepAliveTime，验证回收逻辑是否正常触发
- 在流量低谷期通过 JMX 或 Actuator 动态调整 keepAliveTime（需确保线程池支持运行时修改）
例如发现夜间线程始终维持在 6 不回落，但 keepAliveTime 设为 60s，说明可能有长任务阻塞或队列未满导致未扩容，需回查任务执行模型。
