admin 先称赞后看，养成好习惯
有一天，云飞哥哥突然来找我。“我警告你们，你们的Java服务内存使用量太高了！GC以后也不释放，只要增加内存就不会减少，是不是内存泄漏了！”
然后我赶紧监视。一切正常。离上次落脚已经好几天了，没有一次全GC，YoungGC，十分钟一次，一堆闲散也够了。(大卫亚设)。
运维：“你们这个服务现在堆内存 used 才 800M，但这个 JAVA 进程已经占了 6G 内存了，是不是你们程序出啥内存泄露的 bug 了！”
我想都没想，直接回了一句：“不可能，我们服务非常稳定，不会有这种问题！”
不过说完之后，内心还是自我质疑了一下：会不会真有什么bug？难道是堆外泄露？线程没销毁？导致内存泄露了？？？
然后我很“镇定”地补了一句：“我先上服务器看看啥情况”，被打脸可就不好了，还是不要装太满的好……
迅速上登上服务器又仔细地查看了各种指标，Heap/GC/Thread/Process 之类的，发现一切正常，并没有什么“泄漏”的迹象。
和运维的“沟通”
我们这个服务很正常啊，各个指标都ok，什么内存只增不减，在哪呢
运维：你看你们这个 JAVA 服务，堆现在 used 才 400MB，但这个进程现在内存占用都 6G 了，还说没问题？肯定是内存泄露了，锅接好，赶紧回去查问题吧
然后我指着监控信息，让运维看：“大哥你看这监控历史，堆内存是达到过 6G 的，只是后面 GC 了，没问题啊！”
运维：“回收了你这内存也没释放啊，你看这个进程 Res 还是 6G，肯定有问题啊”
我心想这运维怕不是个der，JVM GC 回收和进程内存又不是一回事，不过还是和得他解释一下，不然一直baba个没完
“JVM 的垃圾回收，只是一个 逻辑上 的回收，回收的只是 JVM 申请的那一块逻辑堆区域，将数据标记为空闲之类的操作，不是调用 free 将内存归还给操作系统”
运维顿了两秒后，突然脸色一转，开始笑起来：“咳咳，我可能没注意这个。你再给我讲讲 JVM 的这个内存管理/回收和进程上内存的关系呗”
虽然我内心是拒绝的，但得罪谁也不能得罪运维啊，想想还是给大哥解释解释，“增进下感情”
操作系统 与 JVM的内存分配
JVM 的自动内存管理，其实只是先向操作系统申请了一大块内存，然后自己在这块已申请的内存区域中进行“自动内存管理”。JAVA 中的对象在创建前，会先从这块申请的一大块内存中划分出一部分来给这个对象使用，在 GC 时也只是这个对象所处的内存区域数据清空，标记为空闲而已
运维：“原来是这样，那按你的意思，JVM 就不会将 GC 回收后的空闲内存还给操作系统了吗？”
为什么不把内存归还给操作系统？
JVM 还是会归还内存给操作系统的，只是因为这个代价比较大，所以不会轻易进行。而且不同垃圾回收器 的内存分配算法不同，归还内存的代价也不同。
比如在清除算法（sweep）中，是通过空闲链表（free-list）算法来分配内存的。简单的说就是将已申请的大块内存区域分为 N 个小区域，将这些区域同链表的结构组织起来，就像这样：
每个 data 区域可以容纳 N 个对象，那么当一次 GC 后，某些对象会被回收，可是此时这个 data 区域中还有其他存活的对象，如果想将整个 data 区域释放那是肯定不行的。
所以这个归还内存给操作系统的操作并没有那么简单，执行起来代价过高，JVM 自然不会在每次 GC 后都进行内存的归还。
怎么归还？
虽然代价高，但 JVM 还是提供了这个归还内存的功能。JVM 提供了 -XX:MinHeapFreeRatio 和 -XX:MaxHeapFreeRatio 两个参数，用于配置这个归还策略。
Xmx
Xms不同版本&垃圾回收器下的表现不同
下面是我之前跑过的测试结果：
public static void main(String[] args) throws IOException, InterruptedException {
List<Object> dataList = new ArrayList<>();
for (int i = 0; i < 25; i++) {
byte[] data = createData(1024 * 1024 * 40);// 40 MB
da(data);
}
T(10000);
dataList = null; // 待会 GC 直接回收
for (int i = 0; i < 100; i++) {
// 测试多次 GC
Sy();
T(1000);
}
Sy();
}
public static byte[] createData(int size){
byte[] data = new byte[size];
for (int i = 0; i < size; i++) {
data[i] = By;
}
return data;
} 测试结果刷新了我的认知。，MaxHeapFreeRatio 这个参数好像并没有什么用，无论我是配置40，还是配置90，回收的比例都有和实际的结果都有很大差距。
但是文档中，可不是这么说的……
而且 ZGC 的结果也是挺意外的，JEP 351 提到了 ZGC 会将未使用的内存释放，但测试结果里并没有。
除了以上测试结果，stackoverflow 上还有一些 其他的说法 ，我就没有再一一测试了
-XX:-ShrinkHeapInSteps所以，官方文档的说法，也只能当作一个参考，JVM 并没有过多的透露这个实现细节。
不过这个是否归还的机制，除了这位“热情”的运维老哥，一般人也不太会去关心，巴不得 JVM 多用点内存，少 GC 几回……
而且别说空闲自动归还了，我们希望的是一启动就分配个最大内存，避免它运行中扩容影响服务；所以一般 JAVA 程序还会将 Xms 和 Xmx 配置为相等的大小，避免这个扩容的操作。
听到这里，运维老哥若有所思的说到：“那是不是只要我把 Xms 和 Xmx 配置成一样的大小，这个 JAVA 进程一启动就会占用这个大小的内存呢？”
我接着答到：“不会的，哪怕你 Xms6G，启动也只会占用实际写入的内存，大概率达不到 6G，这里还涉及一个操作系统内存分配的小知识”
Xms6G，为什么启动之后 used 才 200M？
进程在申请内存时，并不是直接分配物理内存的，而是分配一块虚拟空间， 到真正堆这块虚拟空间写入数据时才会通过缺页异常（Page Fault）处理机制分配物理内存 ，也就是我们看到的进程 Res 指标。
可以简单的认为操作系统的内存分配是“惰性”的，分配并不会发生实际的占用，有数据写入时才会发生内存占用，影响 Res。
所以，哪怕配置了 Xms6G ，启动后也不会直接占用 6G 内存，实际占用的内存取决于你有没有往这 6G 内存区域中写数据的。
运维：“wc，还有惰性分配这种东西！长知识了”
我：“这下明白了吧，这个内存情况是正常的，我们的服务一点问题都没有”
运维：“:ox::beer:，是我理解错了，你们这个服务没啥问题”
我：“嗯呐，没事那我先去忙（摸鱼）了”
总结
对于大多数服务端场景来说，并不需要JVM 这个手动释放内存的操作。至于 JVM 是否归还内存给操作系统这个问题，我们也并不关心。而且基于上面那个测试结果，不同 JAVA 版本，不同垃圾回收器版本区别这么大，更是没必要去深究了。
综上，JVM 虽然可以释放空闲内存给操作系统，但是不一定会释放，在不同 JAVA 版本，不同垃圾回收器版本下表现不同，知道有这个机制就行。
推荐阅读：Java开发offer拿到手软 分享485页“1000道Java工程师面经”接好运
看到这里的小伙伴，点个赞，点个关注再走叭