如何让 JVM 几乎不发生 full gc

一、业务流程简图

如何让 JVM 几乎不发生 full gc_第1张图片

二、问题分析

如何让 JVM 几乎不发生 full gc_第2张图片

1️⃣一个 4 核 8G 的订单系统,假设给 JVM 运行内存为 3 个G,根据堆内存划分比例老年代可分 2G,Eden 800M,S0/S1 各 100M。
2️⃣线程运行每秒产生 60M 对象,大概运行 13 秒就会占满 Eden 区,前 12 秒产生的对象在做一个 minor gc 后被当作垃圾对象处理掉,第 13 秒产生的对象不是垃圾对象,会被放到 S0 区。
3️⃣第 13 秒产生的 60M 对象由于大于 S0 区的 50% 所以会被放到老年代。为了能更好地适应不同程序的内存状况,HotSpot虚拟机并不是永远要求对象的年龄必须达到 -XX:MaxTenuringThreshold 才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到 -XX:MaxTenuringThreshold 中要求的年龄。
因此每隔 13 秒就有 60M 对象会被放到老年代,大概 7 到 8 分钟就会放满老年代,老年代放满后就会产生一次 full gc,此时老年代里 99% 的对象是垃圾对象,会被清理掉。而一次 full gc,会收集整个堆的垃圾对象,时间过长。因此系统每隔七八分钟就会有持续性的卡顿现象

三、能否对JVM调优,让其几乎不发生full gc

Full GC 最根本的产生原因就是有对象不停的进入老年代,最后导致空间不足,引发 Full GC。解决思路就是直接破坏掉产生条件,直接减少运行时期间从新生代晋升到老年代的对象,或者没有对象晋升到老年代就行了。具体措施:

1️⃣大对象频繁进行老年代,造成老年代空间快速被占满,造成 Full GC。

解决方案:合理配置-XX:PretenureSizeThreshold大小。避免过多非必要对象进入老年代。

2️⃣metaspace 空间不足

解决方案:一般这个里面存放的都是一些 Class 类信息,Class 本身也是一个对象,需要空间存放。那么程序代码中什么时候会产生对象进入呢,当使用 CGLIB 动态代理不停的生成代理类的时候,就会加载到元数据空间,当然一般 4 核 8G 内存的物理机分配个 512M 是完全没问题的。

3️⃣从年轻代晋升到老年代的对象

  1. 【长期存活对象】达到了设置的年龄限制,默认是 15 次。
  2. Young GC 后,存活对象大于 survivor 区,存活对象全部进入老年代,注意动态年龄的区别。
  3. 【动态年龄判定】如果在 Survivor 空间中相同年龄所有对象大小的总和大于
    Survivor 空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代。

解决方案:

  1. 针对【长期存活对象】调大晋升年龄没有多大意义。假设 10 秒一次 Young GC 15 * 10 = 150s,存活两分钟的对象,可以认为是系统中长期存活的对象,调大一点,也仅仅是让它在新生代在多待一会儿,还不如让它早点去它该区的老年区。

  2. 存活对象大于存活区大小和【动态年龄判定】二者产生原因差不多,都是 Survivor 区大小分配不合理,可以同时进行优化。核心思想就是合理分配新生代老年代内存比例大小。

如何让 JVM 几乎不发生 full gc_第3张图片

如图调整内存比例,线程运行每秒产生 60M 对象,大概运行 28 秒就会占满 Eden 区,此时前 27 秒产生的对象在做一个 minor gc 后被当作垃圾对象销毁掉,第 28 秒产生的对象会被放到 S0 区,由于 60M 小于 S0 区的 50% 不会被放到老年代。当 Eden 再一次放满,此时 minor gc 会销毁 Eden 中前 27 秒的垃圾对象和 S0 中的对象,Eden 第 28 秒产生的对象会被放到 S1 区。当 Eden 再一次放满,minor gc 会销毁 Eden 中前 27 秒的垃圾对象和 S1 中的对象,Eden 第 28 秒产生的对象会被放到 S0 区,如此 JVM 几乎不发生 full gc。

四、线上如何去思考内存分配

  1. 找到最大的压力瓶颈点,也可以说并发最多的点。

  2. 根据系统未来的业务量,访问量,去推算这个系统每秒的并发量,注意项目的特殊性,一般可以用二八原则。

  3. 计算一次业务新生代会占用多少内存,一般可以考虑主要业务对象大小扩大10~20倍来预估,或者直接用工具直接监测。

  4. 一次业务的时长,即一次请求的耗时。

  5. 根据 1 和 2 中推算的每秒的并发量预估推算对内存空间的占用量,这个占用量是一秒内或者说在并发过程中无法回收的。无法回收的对象大小 = 业务处理时间 * QPS * 每个处理会产生的对象大小

  6. 根据内存的推算结果预估出运行期间 JVM 的内存运转模型。

  7. 部署多少台机器,每台机器配置如何。

你可能感兴趣的:(如何让 JVM 几乎不发生 full gc)