keepalivetime 控制空闲非核心线程存活时长，仅对超过corepoolsize的线程生效，需与队列类型、maximumpoolsize协同调优，并按业务负载节奏设定合理值。
线程池的 keepAliveTime 不是“保活连接”，而是控制空闲非核心线程存活时长的关键机制。它不提升单次响应速度，但能动态调节线程数量，在流量回落时及时回收资源，从而在响应能力与内存/CPU开销之间取得实际平衡。
理解 keepAliveTime 的真实作用边界
该参数只对超过 corePoolSize 的那部分线程生效：当任务激增、队列填满后扩容出的线程，在空闲超过 keepAliveTime 后会被销毁。核心线程默认永驻（除非显式开启 allowCoreThreadTimeOut(true)）。这意味着：
- 它不干预线程创建时机，只影响“用完之后是否留下”
- 它不能加速任务启动，但能防止低谷期线程冗余堆积
- 设置过短（如 100ms）会导致频繁扩缩容，增加上下文切换开销
- 设置过长（如 30 分钟）会使线程长期占内存，失去弹性价值
按业务负载节奏设定合理值
keepAliveTime 应匹配你系统典型的“空闲窗口”长度，而非拍脑袋定 60 秒：
- 高频短任务（如 API 网关请求）：5–20 秒。请求来得密、走得快，线程可快速释放
- 中低频批处理（如定时报表生成）：60–180 秒。任务间隔较明显，留稍长时间避免反复重建
- 突发型后台作业（如大促订单补偿）：建议配合
allowCoreThreadTimeOut(true)+ 30–120 秒，让整个池具备全量收缩能力
与队列、最大线程数联动调优
单独调 keepAliveTime 效果有限，必须和 workQueue 容量、maximumPoolSize 协同设计：
- 用有界队列（如 ArrayBlockingQueue）+ 中等 keepAliveTime（60s）：队列先缓冲，溢出再扩容，扩容线程用完即走 → 内存可控、响应不卡顿
- 用无界队列（LinkedBlockingQueue）+ keepAliveTime 无效：因队列永不满，线程永远不扩容，keepAliveTime 失去意义；此时应改用有界队列或限制 maximumPoolSize 为 1
- maximumPoolSize 过大 + keepAliveTime 过长：高并发后残留大量线程，拖慢 GC、抬升 RSS 内存占用
通过监控验证调优效果
上线后重点观察三个指标是否收敛：
- pool.getActiveCount() 峰值是否接近 maximumPoolSize（说明扩容生效）
- pool.getPoolSize() 谷值是否回落至 corePoolSize（说明 keepAliveTime 触发回收）
- 队列 size() 持续 > 80% 容量：说明 keepAliveTime 太长或 maximumPoolSize 太小，线程没及时扩容
不复杂但容易忽略
