线程空闲回收仅销毁非核心线程以降低rss和上下文切换开销，不释放变量内存；栈空间需通过-xss精控，虚拟线程可解耦线程与变量生命周期，配合有界队列防堆溢出。
线程空闲回收逻辑本身不直接管理“变量内存分配”，它只控制非核心线程在空闲超时后是否被销毁。容器化环境下真正影响变量内存分配的，是线程栈空间配置、任务执行模型（如是否使用虚拟线程）、以及对象生命周期与GC行为。优化需从三方面切入：回收策略适配、栈内存精控、变量分配模式重构。
明确空闲回收的作用边界
keepAliveTime + unit 仅作用于非核心线程：当线程池中线程数 > corePoolSize，且某非核心线程空闲超过该时间，就会被终止。它不释放局部变量或堆对象，也不影响栈大小——栈内存在线程创建时就已由JVM或OS分配，线程销毁时才整体归还。
- 误用场景：把 keepAliveTime 设得很小（如 10ms），期望“快速释放变量内存”——无效，变量生命周期由作用域和GC决定，与线程存活时长无直接关系
- 正向价值：避免非核心线程长期驻留，减少容器内不必要的线程数，从而降低 RSS 内存占用和上下文切换开销
- 容器敏感点：Kubernetes 中 Pod 的 memory limit 是硬限制，过多空闲线程会推高 RSS，可能触发 OOMKilled
配合容器内存约束调优栈空间
每个平台线程默认栈约 1MB（JVM -Xss1m），100 个空闲非核心线程就占 100MB RSS。在容器内存受限（如 512MB Pod）时，这是隐形风险。
- 显式缩小栈：启动参数加 -Xss256k 或 -Xss512k，适用于多数 I/O 密集型服务（如 HTTP 客户端、数据库连接池回调）
- 验证方式：用 cat /proc/
/maps | grep stack 查看实际栈映射大小，确认生效 - 注意：递归深度大或本地变量多的场景需保留足够栈空间，否则抛 StackOverflowError
用虚拟线程替代平台线程，从根本上解耦变量与线程生命周期
Java 21+ 虚拟线程让“每任务一线程”成为安全实践。其栈内存按需分配（KB 级），空闲时自动挂起、不占载体线程，变量仍在堆上，但线程维度的内存压力趋近于零。
- 替换传统线程池：用 Executors.newVirtualThreadPerTaskExecutor() 替代 FixedThreadPool 或 CachedThreadPool
- 变量分配不变：局部变量仍在线程栈（虚拟栈），但该栈由 JVM 管理、轻量、可回收；对象仍分配在堆，由 GC 统一回收
- 容器收益：同等并发下 RSS 下降 80%+，CPU 切换开销锐减，适合 Spring Boot WebMvc 或 gRPC Server 等高连接数场景
结合工作队列与拒绝策略，防止变量堆积引发堆溢出
空闲回收不解决任务积压问题。若 workQueue 过大（如 LinkedBlockingQueue 不设界），待执行任务携带的闭包对象会长期驻留堆中，导致老年代膨胀。
- 推荐使用有界队列：如 new ArrayBlockingQueue
(1024) ，配合 CallerRunsPolicy 或 AbortPolicy，让上游感知背压 - 关键点：任务对象本身（如 Runnable 实现类）若持有大对象引用（如 byte[]、List），需在 run() 结束前显式置 null 或用 try-with-resources 释放
- 容器监控建议：通过 Micrometer 暴露 thread.pool.queue.size 和 jvm.memory.used，设置 Prometheus 告警
