JAVA的平凡之路——此峰乃是最高峰JVM-附加小菜-04
2026/7/4 16:35:06 网站建设 项目流程
图1.1

每台机器300/s,每个订单对象假设1KB,300KB/s

可能会涉及其他对象放大20倍,并且可能涉及其他操作情况,再放大10 300*20*10 大约每秒60MB/s

当前堆内存 3072 MB,新生代占1/3,大约 1g ,并且eden 8/10.,s1和s2分别 1/10,分别800、100、100MB

能否JVM优化,几乎不发生FullGC

运行14秒左右eden区会占满 所以 14秒会执行一次MinorGC

正常Web 0.05的生命存活率

800 * 0.05 = 40 M

按照年龄为 15 每次晋升

40m/ 15 = 2.6 mb/次

2024/2.6=778 次

778 * 14 / 60 = 181 分钟 = 3 小时 但是我们按照的是最小情况

如果 由于s1 、s2空间不足 导致大量对象直接老年代呢,那么2.6可能不太现实,可能更贴切的是

正常晋升不太贴切现实正常来说,25%可能更贴近 40 * 0.25 = 10 m/次

2048/10 = 204次

204 * 14 / 60 = 46 分钟 那么 你就g了

主要的原因是因为 minorgc 速度太快 那么把它扩大 速度降下来那么 降下来

1600 eden区 s1 200 s2 200 老年代 1024

28秒占满 eden

1600 * 0.05 = 80M

80 * 0.25 = 20m

1024 / 20 = 52

52 * 28 / 60 = 46分钟

是不是感觉算的一样,你没算错,我们没有加上s1、s2区的变量,它比原来大了一倍,那么在分代年龄处理时,它会比原有方案 更复合正常晋升 那么 按照 每次晋升 为 10mb

那么fullgc的时间会被延长到 1个半小时,但是峰值已经过去可能gc就已经可以稳定处理了

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询