【求助】线上生产环境遇到频繁Full GC，eden和2个survivor区一样大

xiueer 2019-01-23 07:49:40

大婶好
小弟在的一个线上生产环境频繁Full GC的问题
设置的参数是
Xms=1800M
Xmx=1800M
XX:SurvivorRadio未设置，默认是8

jmap -heap pid发现eden区，survivor1区，survivor2区大小相同，而不是默认的8:1:1的比例
请问这是什么原因造成的啊
[GC日志]

[相关参数]

...全文

436 1 打赏收藏转发到动态举报

写回复

1 条回复

切换为时间正序

请发表友善的回复…

发表回复

xiueer 2019-01-23

打赏
举报

回复

明天把更多参数补充进来

本课程将介绍JVM的核心原理，包括类加载机制的设计原理，JVM常用的参数类型，对堆内存中的Eden，S0，S1和Old区的理解，如何确定一个对象为垃圾？常用的垃圾回收算法和垃圾收集器，以及它们适用的区域和特点等等，...

排查gc思路、方法论、过程由于1-4的步骤通常可以让运维去执行，目前公司生产则一律由运维管理，所以直接找运维dump堆内存文件即可 1、检查JVM配置 2、观察监控信息中老年代内存变化 3、通过jmap命令查看堆内存中的对象通过命令 jmap -histo 7276 | head -n20 图片是借助网图，因生产没权限只有运维来执行

1 原因原因一：系统承载高并发请求，或者处理数据量过大，导致Young GC很贫乏，而且每次Young GC过后存活对象太多，内存分配不合理，Survivor区过小，导致对象频繁进入老年代，频繁触发Full GC。原因二：系统一次性加载过多数据进内存，搞出来很多大对象，导致频繁有大对象进入老年带，必然频繁触发Full GC。原因三：系统发生了内存泄漏，莫名其妙创建大量的对象，始终无法回收，一直占用在老年代里，必然频繁触发Full GC。原因四：Metaspace（永久代）因为加载类过多触发Full

指发生在新生代的垃圾收集动作，Minor GC非常频繁，<b>新生代采用复制算法</b>，一般回收速度也比较快。因为采用复制算法，所以年轻代分为三部分：**1个Eden区和2个Survivor区（分别叫From和To）**，默认比例为8：1。GC的流程如下

偶然想起JVM年轻代中Eden区和两个Survivor的比例，就想根据自己的理解和大家探讨一下为什么要配成8 ：1 ：1的比例。一、JVM堆分代 1、JVM堆被分为了年轻代和老年代。年轻代的GC过程称为Yong GC，速度快较频繁。老年代的GC过程称为Full GC，速度较慢应该尽量避免。 2、对象被创建后，除了少部分大对象会在老年代分配内存外，大部分的对象首先都是在年轻代进行内存分配，而...

50,530

社区成员

85,610

社区内容

发帖

与我相关

我的任务

javaspring bootspring cloud 技术论坛（原bbs）

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章