每台机器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就已经可以稳定处理了
风险查询的高性能客户端)
