升级至Java 17后Eden Space与Old Gen峰值内存异常升高问题咨询

这大概率不属于传统意义上的内存泄漏，核心判断依据是你提到的「Old Gen最低值未增长」——内存泄漏的典型特征是无法被GC回收的对象持续累积，最终会导致堆内存的基线（最低值）不断上升，直至触发OOM。而你的场景中堆内存只是峰值升高、增长速度变快，但回收后能回到原有基线，结合内存转储无泄漏、GC指标正常的情况，更可能是JVM版本升级带来的内存策略或对象布局变化，以下是具体分析：

可能的原因 #

• GC默认策略调整：Java 17的G1GC（默认垃圾收集器）相比Java 11做了多项优化，比如自适应堆调整逻辑、停顿目标的动态校准。为了降低GC停顿时间，新版本G1可能会更倾向于保留更多空闲堆内存，或者调整Eden/Old Gen的扩容阈值，导致堆内存的峰值上限被拉高，但回收机制依然正常。
• 对象内存布局变化：Java 17对对象头、字段对齐等内存布局做了细节调整，部分场景下相同数量的对象会占用更多堆内存。比如某些类型的实例大小增加，导致相同业务负载下的内存峰值自然升高，但GC依然能正常回收这些对象，不会留下无法释放的内存。
• JDK内部特性的隐式开销：Java 17引入的新特性（如密封类、模式匹配等）或JDK内部类的实现优化，可能会带来额外的临时对象或内部缓存，这些内存占用属于正常的运行时开销，GC会在合适的时机回收，不会造成泄漏。

验证与排查建议 #

• 对比相同业务负载下，Java 11和Java 17的内存转储对象分布：重点看是否有某类对象的数量明显增加，但这些对象的引用链是可达且可回收的（比如临时缓存、线程本地变量等）。
• 检查JVM启动参数一致性：确认-Xmx、-Xms以及GC相关参数（如-XX:MaxGCPauseMillis、-XX:G1HeapRegionSize）在两个版本中是否一致，新版本的默认参数可能导致堆的动态调整行为变化。
• 长期运行观察：如果堆内存峰值最终稳定在某个区间，不再持续无上限上升，即可彻底排除内存泄漏的可能；若后续出现基线持续上升的情况，再重新排查泄漏点。

内容的提问来源于stack exchange，提问作者hellzone