我们这边没用k8s，是自研的平台，但也有整体的内存监控，一般是定位到异常机器后找相关实例的jvm数据，各区内存增长曲线、jstat、jmap之类，如果是native mem泄露，可能需要上一些定制化小工具

【 在 vole 的大作中提到: 】
: 那测试java po是否有内存泄露只能看jstat而不能用k8s的监控系统了？
--
FROM 111.206.214.*

Java 12,增强 G1 垃圾收集器，使其能自动返回未用堆内存给操作系统

G1 定期垃圾收集的类型根据 G1PeriodicGCInvokesConcurrent 参数的值确定：如果设置值了，G1 垃圾回收器将继续上一个或者启动一个新并发周期；如果没有设置值，则 G1 回收器将执行一个完整的 GC。在每次一次 GC 回收末尾，G1 回收器将调整当前的 Java 堆大小，此时便有可能会将未使用内存返还给操作系统。新的 Java 堆内存大小根据现有配置确定，具体包括下列配置：- XX:MinHeapFreeRatio、-XX:MaxHeapFreeRatio、-Xms、-Xmx。
【 在 vole 的大作中提到: 】
: 是不是有啥配置可以让他还回去?
--
FROM 111.207.106.*

赞

真高手

【 在 IcyFenix 的大作中提到: 】
: 有配置的。不过这个与收集器和版本相关，所以能否满足你的期望不好说。
:
: 在JDK 8及之前，哪怕GC之后占用内存下降，得到的内存空间也仅仅是从Used转变为Committed，在JVM一侧看这些已经是空闲内存了，但在OS一侧看来，仍然是被JVM占用的状态。
: ....................

- 来自「最水木 for iPhone13,2」
--
FROM 120.244.232.*

好像说了下原因

https://bugs.openjdk.java.net/browse/JDK-8146436

This is useful for customers that want to minimize the amount of memory used by the java heap, and are willing to sacrifice some performance (induce more frequent GCs) to save that memory. When heap usage fluctuates greatly, the GC will tend to hold on to the excess heap memory longer than needed due to the the current algorithm which requires 4 full GCs before MaxHeapFreeRatio is fully honored. +UseAggressiveHeapShrink will eliminate the need to wait for 4 full GCs.


【 在 chzhang7901 的大作中提到: 】
: 把内存还给os有什么用？
:
:
: ....................

- 来自「最水木 for iPhone13,2」
--
FROM 120.244.232.*

膜拜周总
【 在 IcyFenix ().println("helloworld") 的大作中提到: 】
: 有配置的。不过这个与收集器和版本相关，所以能否满足你的期望不好说。
: 在JDK 8及之前，哪怕GC之后占用内存下降，得到的内存空间也仅仅是从Used转变为Committed，在JVM一侧看这些已经是空闲内存了，但在OS一侧看来，仍然是被JVM占用的状态。
: 从JDK 9起，加入了ShrinkHeapInSteps参数，或者说修复了以前的UseAggressiveHeapShrink参数的问题（https://bugs.openjdk.java.net/browse/JDK-8146436），让OS一侧能看到JVM主动释放的内存。
: ...................
--
FROM 119.131.107.*