概述
最近遇到了一个奇怪的内存问题，两个服务各自单独处理吞吐量都能达到70条/秒，但是合并处理之后就只有不到20，明显的不符合逻辑。
查看处理状态，使用jstat跟踪内存使用情况，发现一个奇怪的现象，当eden区的内存占满后并不出发minor
gc，而是直接触发了full gc。一直都是这样的状态。
这个服务的基础内存配置是-Xmx2900m，-server启动，其他没有特殊配置
使用jmap
heap查看各个内存区的使用情况，整个young区分了950m，整个old区分了1950m
young里面eden占了700多m，s1和s2分别是120多m
服务处理过程中old区剩余始终维持在500m，也就是说每次full
gc都会把young区升级至old区的对象回收掉
实际晋升至old区的对象如此只少，为什么不进行minor gc呢
最终发现原因是java虚拟机在内存回收中的一个担保机制引起的
虚拟机在执行minor gc前会做风险评估，主要做两个评估
第一个是看old区的连续空余空间是否能够放下全部的young区内容
如果第一个风险判断是false
那么就进行第二个判断，最近一段时间内的连续晋升至old区的平均有效大小是否小于old区的连续剩余空间
如果这个风险判断也是false
那么就会强制进行full gc
再看回这次的问题
这两个合并的服务都有大对象，这些大对象加起来需要在old区占用1400m的空间
这1400m的大小两次minor gc就加载完了
这时old区就只剩500m的空间了
这时再进行minor gc的时候这两次考察分别是
第一eden700m+一个s1 120 800多m 大于了500m
第二之前两次minor
gc晋升至old区的平均有效大小是700m，也大于剩余的500m(当然这里最大的连续剩余内存肯定会小于这个值)
这就导致了担保失败，直接触发full gc
解决方案就是减少young区，使用-Xmn减少一些就够了
就这次减少到700m就能够稳定运行了
不再出现担保失败的现象
上面这些对内存的运行期的描述可以通过java添加gc日志相关的参数打印出来，看起来比较直观
最后
以上就是爱笑抽屉为你收集整理的java gc full gc_JAVA虚拟机注意大对象引起的Full GC的全部内容，希望文章能够帮你解决java gc full gc_JAVA虚拟机注意大对象引起的Full GC所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复