堆内存回收不及时需优化对象生命周期与晋升策略：①调低-xx:maxtenuringthreshold至6、提高-xx:targetsurvivorratio至90、减小-xx:survivorratio至4以抑制过早晋升；②选用g1或zgc等低延迟收集器替代parallel或cms。
堆内存回收不及时，通常表现为老年代持续增长、Full GC 频繁、GC 后内存回落少，甚至最终 OOM。这不是单纯“加大堆”就能解决的问题，关键在于让对象生命周期更合理、晋升更可控、回收更精准。下面从三个最常出问题的环节切入，给出可直接落地的参数调整方向。
看老年代是否过早或过快填满
如果监控发现老年代占用率稳步上升、YGC 后 Survivor 区几乎清空但老年代却明显上涨，说明大量对象没活过几次 Minor GC 就晋升了——这是典型的“晋升过快”。这时要抑制晋升，而不是加堆。
- -XX:MaxTenuringThreshold=6：把默认的 15 降低到 6，缩短对象在新生代的“存活考验期”
- -XX:TargetSurvivorRatio=90：提高 Survivor 区目标使用率，避免因空间不足被迫提前晋升
- -XX:SurvivorRatio=4：调小 Eden 与单个 Survivor 的比例（比如从默认 8 改为 4），等效扩大 Survivor 容量，多留对象多熬几轮 GC
选对收集器并设好停顿目标
回收不及时，有时不是“不想收”，而是收集器根本没被触发或策略不匹配。比如 Parallel GC 只关心吞吐，不控停顿；CMS 已废弃且易并发失败；而 G1 或 ZGC 才是当前主流选择。
- 若应用延迟敏感（如接口响应要求 -XX:+UseG1GC -XX:MaxGCPauseMillis=150
- 若堆 ≥ 8G 且 JDK ≥ 11：-XX:+UseZGC，基本消除 STW，适合高吞吐+低延迟双重要求
- 避免用 -XX:+UseParallelGC 处理 Web 类服务——它会拉长单次停顿来换吞吐，反而加剧“卡顿感”
检查元空间和直接内存是否偷偷吃掉堆外资源
有时候“堆没满但回收卡住”，其实是 Metaspace 或 Direct Memory 溢出，导致 JVM 触发保守 Full GC 或拒绝分配，表现就像堆回收失灵。
- -XX:MaxMetaspaceSize=512m：硬性限制元空间，防止动态类加载（如 Spring Boot DevTools、热更新框架）撑爆内存
- -XX:MaxDirectMemorySize=1g：NIO 操作常用直接内存，默认等于 -Xmx，必须显式设限，否则可能抢走堆内存资源
- 加日志确认：-Xlog:gc*,metaspace*,directmemory*，定位到底是哪块内存在拖后腿
