前言
早期面试的时候最害怕面试官问有没有过JVM调优的经验，一听这个问题腿肚子直转筋，JVM八股文都没背多熟练呢，调啥优啊，唠嗑唠的让人害怕，工作一段时间发现不就是基于服务当时所在环境和现象根据JVM现有参数调参嘛，今天记一个JVM内存相关参数。
某天下午运维反应集成环境的一个Java服务内存飙高，看到消息我第一反应就是高就高呗，这不Java本身的特点，高你就多让给它点内存得了，嫌高用Go重构。后来运维说内存耗的太高了，疑似内存泄漏。那得认真分析一波了，别到时候上线发版出了大问题，事关众后端将士的绩效高低，我义不容辞。
内存分析
排查Java进程三板斧，先TOP看资源情况，shit+M按内存排序看是个用户中心的服务，当时看用了接近20G左右，非常高了，集成环境都是研发测试用的环境，没有多少访问量怎么会有这么高的内存使用量。看来多半是泄露了。
分析内存泄露其实也不难，我们先拿到pid浅浅的运行下
less
jmap -histo:live [pid] > a.txt这是获取当前进程中存活的对象统计并把结果输出到a.txt中，从高到低排序，直接看排在前几位的对象有没有我们的业务对象，如果有的话那差不多就逮到了，顺着这个类找一下对应的逻辑分析一下基本就能定位到。但是执行完查询发现排在前几位都是jdk中的class，第一位是c[（代表数组，char\[数组最多也正常，因为String底层就是char\[\]，而且String应用的地方也比较多）
这里已经开始挠头了，不太对啊，按理说内存泄漏肯定是业务中用的类占比会多，再不济也应该是map占用高，这里明显不太符合泄露的现象。。。
分析一下每5s的gc情况发现也都很平稳。
yaml
jstat -gc pid 5000那只能分析dump文件了，可以借助fastThread.io分析dump，也可以搞个JProfile分析。
lua
jmap -dump piddump之后导入Jprofile发现整体内存占用才2G多，这就很诡异了，从现象上来看像是假装用了20g内存实际只用了2g，这是咋回事呢。
解决方案
本质上是jvm是在启动的时候就会向操作系统申请一部分内存，然后占着自己再做内存管理，当分配对象被回收之后也只是在这个内存区域清除数据然后标记空闲，也就是说根本不会归还给操作系统。根本原因是归还操作系统成本较高，不同的垃圾回收器也有不同的规则。
一直占着也不是个事，JVM还是提供了设置归还策略的参数，MaxHeapFreeRatio ，当空闲区域超过该值时，会进行内存回收，剩余空间的下限为Xms，回收的过程也是线性回收并不是到点下班，到了MaxHeapFreeRatio内存立马降下来。
根据网上大佬们的结论，不同的垃圾回收器下的表现也不一样，详细的结论大家可以自行再去研究。
| JAVA 版本 | 垃圾回收器 | 参数 | 是否可以"归还" |
|---|---|---|---|
| JAVA 8 | ParallerGC + ParallerOld | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 | 否 |
| JAVA 8 | CMS+ParNew | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC | 是 |
| JAVA 8 | G1 | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseG1GC | 是 |
| JAVA 11 | G1 | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 | 是 |
根据以上结论将服务启动命令增加了-XX:++UseG1GC -XX:MaxHeapFreeRatio=50(最大空闲比例超过50%归还)参数后内存过高的问题的确没有再出现。