keepAliveTime仅控制空闲非核心线程存活时长，不回收ThreadLocal资源；需手动调用remove()并结合短超时、allowCoreThreadTimeOut、任务封装清理等协同防范内存泄漏。
keepAliveTime 本身不直接回收“线程变量资源”，它只控制空闲非核心线程的存活时长；真正实现变量资源自动回收，需结合 ThreadLocal 的生命周期管理、线程复用特性与合理的线程池配置协同完成。
理解 keepAliveTime 的真实作用范围
keepAliveTime 是 ThreadPoolExecutor 中针对 超出 corePoolSize 但未达 maximumPoolSize 的那些非核心线程 设置的空闲等待时间。一旦线程空闲超过该时长，就会被终止。它不干预线程内局部变量或堆对象，也不主动清理 ThreadLocal 中的值。
- 仅影响线程对象本身的存续：线程终止 → 其持有的 ThreadLocalMap（含所有 ThreadLocal 变量副本）随线程消亡而被 GC 回收
- 若线程被复用（未超时），ThreadLocal 值会持续残留——这是内存泄漏高发场景
- 默认 keepAliveTime=60L（秒），单位由 TimeUnit 指定，需配合 allowCoreThreadTimeOut(true) 才能对核心线程生效
ThreadLocal 资源必须手动清理，不能依赖 keepAliveTime
ThreadLocal 的 value 是以弱引用 key + 强引用 value 方式存于线程的 ThreadLocalMap 中。线程长期存活（如线程池复用）时，若未调用 remove()，value 无法被 GC，尤其当 value 是大对象、数据库连接、IO 流等时，极易引发内存泄漏。
- 务必在业务逻辑结束前显式调用 threadLocal.remove()，推荐放在 finally 块或 try-with-resources 尾部
- 避免使用 static ThreadLocal 持有上下文以外的可变大对象；如需传递上下文，优先考虑传参或 MDC（Logback/Log4j2）等轻量机制
- 可封装工具类，在提交任务时自动 wrap Runnable/Callable，统一做 before/after 处理（如清理指定 ThreadLocal）
实战配置建议：让非核心线程“及时退场 + 清理可控”
目标是缩短非核心线程生命周期，降低 ThreadLocal 残留风险窗口，同时确保清理动作不遗漏。
- 将 keepAliveTime 设为较短值（如 10~30 秒），加快非核心线程回收，减少长期驻留线程数量
- 开启 allowCoreThreadTimeOut(true)，使核心线程也服从 keepAliveTime（适合流量波动大、低峰期需彻底缩容的场景）
- 搭配使用自定义 RejectedExecutionHandler，在任务被拒绝前强制执行一次资源清理钩子（如清空当前线程的特定 ThreadLocal）
- 在线程池 shutdown() 前，遍历活跃线程并触发一次清理（适用于 JVM 关闭前兜底，但生产环境慎用反射操作线程私有字段）
验证是否真正回收：可观测性要点
不能仅靠“线程数下降”判断资源已释放，需关注实际内存与上下文状态。
- 用 JFR 或 Arthas 监控 ThreadLocalMap.size() 变化，确认 remove() 是否生效
- Heap Dump 分析中搜索 java.lang.ThreadLocal$ThreadLocalMap$Entry，观察 value 字段是否仍持有大对象引用
- 在关键 ThreadLocal 的 value 类型中重写 finalize()（仅调试用）或添加日志，观察实例销毁时机是否与线程终止一致
- 压测中对比设置 keepAliveTime=5s 与 60s 时的老年代晋升速率差异，间接反映 ThreadLocal 泄漏程度
