keepAliveTime只控制超出corePoolSize的非核心线程空闲存活时长，需同时满足线程数＞corePoolSize、线程处于TIMED_WAITING空闲状态、空闲时间≥该值且线程池未关闭。
keepAliveTime 控制的是线程池中超出核心线程数（corePoolSize）的那些空闲线程能活多久，不是所有线程都受它管，也不是设了就立刻回收——得同时满足“有非核心线程”“真正在空闲”“空闲时间够长”这三个条件。
keepAliveTime 管谁？怎么才算“起作用”
它默认只对非核心线程生效。比如 corePoolSize=4、maximumPoolSize=12，当负载高峰过去、线程数从12回落到7，那多出来的3个线程（7−4）才会进入 keepAliveTime 倒计时；而最开始那4个核心线程，只要没开 allowCoreThreadTimeOut(true)，就会一直挂着不动。
- 线程必须处于 TIMED_WAITING 状态（比如调用 workQueue.poll(keepAliveTime, unit) 超时返回 null）
- 当前线程总数要大于 corePoolSize，否则没有“多余线程”可回收
- 线程池不能处于 shutdown 或 shutdownNow 状态
常见取值参考与业务匹配逻辑
没有一刀切的数值，关键看任务类型和流量节奏：
- IO 密集型（HTTP 调用、数据库查询）：建议 60~180 秒。线程常卡在 socket read 或连接池获取上，稍留久点能复用连接上下文，减少重连开销
- 计算密集型（图像压缩、批量解析）：建议 10~60 秒。CPU 时间片宝贵，空闲即释放，避免资源占位
- 秒杀退潮后冷期明显：可设 30~120 秒，匹配典型低谷持续时间，既释放资源又不频繁扩缩
- 设为 0L：非核心线程一旦空闲，立刻销毁。适合短时突发、后续长期无请求的场景
想让核心线程也回收？必须配对开启
单独调小 keepAliveTime 对核心线程无效。要真正实现“高并发来时扩容、退潮后归零”，需两步操作：
立即学习“Java免费学习笔记（深入）”；
- 调用 allowCoreThreadTimeOut(true) —— 这是开关，不设它，keepAliveTime 对核心线程完全不生效
- 再设置合理的 keepAliveTime（如 60 秒），此时所有空闲线程（含 corePoolSize 内的）都会按此超时回收
- 注意验证：上线后观察 getPoolSize() 是否能回落到 0 或接近 0，而非卡在 corePoolSize 不动
设错会出什么问题？
过短或过长都不是小事：
- keepAliveTime 太短（如 500ms）：线程刚销毁，新请求又来，反复创建销毁 → 栈内存频繁分配（每个线程约 1MB）、GC 压力上升、上下文切换增多，实测延迟可能升高 20%+
- keepAliveTime 太长（如 30 分钟）：大量空闲线程驻留 → 占用 JVM 线程句柄、操作系统调度资源、堆外内存，在容器环境容易触发 OOMKilled 或被 cgroup 限流
- 搭配无界队列（如 LinkedBlockingQueue 不设容量）：即使 keepAliveTime 合理，线程也可能永远收不回来，因为任务全堵在队列里，线程始终不算“空闲”
