在k8s上的一个java pod，申请完好几G的内存，然后就基本不归还了，不知道是code有问题还是jvm就这样。
--
FROM 222.128.10.*

是不是有啥配置可以让他还回去?
【 在 lindianfeng 的大作中提到: 】
: 默认不会的
--
FROM 223.104.39.*

有配置的。不过这个与收集器和版本相关，所以能否满足你的期望不好说。

在JDK 8及之前，哪怕GC之后占用内存下降，得到的内存空间也仅仅是从Used转变为Committed，在JVM一侧看这些已经是空闲内存了，但在OS一侧看来，仍然是被JVM占用的状态。

从JDK 9起，加入了ShrinkHeapInSteps参数，或者说修复了以前的UseAggressiveHeapShrink参数的问题（https://bugs.openjdk.java.net/browse/JDK-8146436），让OS一侧能看到JVM主动释放的内存。
但这个行为必须是与具体收集器相关的，其他几款收集器的改进并不活跃，G1在这个时期有改动，让它在FullGC时顺带Decommit空闲内存回OS（https://bugs.openjdk.java.net/browse/JDK-8038423）。

不过，以上改进仍然是效果很差，因为G1是并发增量收集，FullGC是很罕见的，所以通常加了这个参数也不容易见到效果。

到了JDK 12，发布了JEP 346（https://openjdk.java.net/jeps/346），这个JEP的改进就是让G1能在正常的不产生FullGC的收集循环中，也能自动Decommit空闲内存回OS（通过G1PeriodicGCInterval参数），后来的Shenandoah收集器也共用了这部分代码。

到了JDK 13，ZGC默认就有Decommit行为，不需要额外参数了。
--
FROM 14.123.255.*

是否归还要看jvm实现，这个和jdk版本相关，从线上部署的角度，一个应用申请多大内存、部署多少个应用是需要提前规划的，超出部分需要监控报警处理，这样可控性更强一些，完全交给OS和jvm实现，可能出现很多坑
--
FROM 111.206.214.*

那测试java po是否有内存泄露只能看jstat而不能用k8s的监控系统了？
【 在 mopo 的大作中提到: 】
: 是否归还要看jvm实现，这个和jdk版本相关，从线上部署的角度，一个应用申请多大内存、部署多少个应用是需要提前规划的，超出部分需要监控报警处理，这样可控性更强一些，完全交给OS和jvm实现，可能出现很多坑
--
FROM 222.128.10.*