JAVA的平凡之路——此峰乃是最高峰JVM-附加小菜-04

每台机器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就已经可以稳定处理了