今早收到一条短信，具体报警信息如下：
【UMP JVM监控内存报警】应用名：发券worker(jdos_couponwkr);KEY【coupon.send.worker.jvm】,主机名:【host-10-183-72-114】,实例【11909223645】的堆内存使用率连续3次超过设定阀值【90.0%】。报警级别:【Warning】,报警时间:【2019-07-17 07:36:12】。
说是有一台机器的堆内存使用超过阈值90%。这条短信虽然言简意赅，但是背后隐藏的技术细节，我这里来陈述一下，谬误之处，还请指教。
初看此报警，则知道堆内存使用超过阈值了。第一反应一般都是把堆内内存调大，就行了。但是事实真的如此吗？不妨来一起看看。
假设我们现在堆内内存为1G，则堆内存使用曲线如下：
可以看到整体使用正常，回收正常，非常平稳。
现在，我们把堆内内存调整为2G，则堆内内存使用曲线如下：
可以看到，堆内内存使用率依然超过90%，说明单纯的调节堆内内存的大小，是无法解决此问题的。
为什么呢？ 由于jvm工作的时候，对堆内内存的使用是自适应的，你给的多，它用的多，你给的少，它用的少。所以这也是为啥你给它1G大小，它能将堆内存用的超过90%，你给他2G大小，他也能将堆内存用的超过90%。当然，前提是应用的内存使用量大于2G才行。否则分配给2G的堆内存，则不会使用这么高。可能用到1.5G左右就释放了。
再来说说垃圾回收机制。这里我将G1算法之外的统称为老算法。咱们来比较一下：
在8G堆内存的docker上，同一个应用，同一业务，压测结果如下：
1. young gc次数，老算法20次，G1算法8次。
2. 堆内存使用最大值，老算法使用最大6.3G，G1算法使用最大7.6G。
可以看出，在8G堆内存的场景下，G1算法整体表现优异，更少的gc次数，更高效率的堆内存使用率。
但是在8G以下堆内存使用的场景中，G1算法则优势并不明显。所以强烈建议堆内存比较大的应用开启G1算法。
最后说下，遇到此短信提示需要检查的内容。
1. 检查yong gc耗时，平均耗时40ms以内正常，超过1s则需要排查问题。
2. 检查full gc次数，一分钟内数次或者数十次则显得频繁，需要排查。
3. 检查堆内存回收图形，如果内存使用率上去了，但是迟迟下不来，则意味着老年代无法回收，检查代码查明原因，类似图形如下：
可以看到此图中，曲线上去后下不来，原因是应用内部有个本地cache一直在运行且无过期机制导致，后来关闭掉此本地cache则回收正常。
4. 根据jvm使用率曲线的最高点来看当前堆内存大小是否符合设置，如果当前堆内存使用率顶点一直较高，则应用需要的内存比分配的堆内存要大一些，可以在内存资源足够的情况下尝试多分配一些堆内存。