哈喽，亲爱的码友们，小郭子又来和你们唠嗑啦，最近有没有变胖呀（hhh）好了，废话不多说，最近小郭子我学习了JVM的优化问题，想分享出来和友友们一起讨论，嘻嘻，走你。

一、问题分析

（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% 所以会被放到老年代。
因此每隔 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）从年轻代晋升到老年代的对象

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

解决方案：

针对【长期存活对象】调大晋升年龄没有多大意义。假设 10 秒一次 Young GC 15 * 10 = 150s，存活两分钟的对象，可以认为是系统中长期存活的对象，调大一点，也仅仅是让它在新生代在多待一会儿，还不如让它早点去它该区的老年区。
存活对象大于存活区大小和【动态年龄判定】二者产生原因差不多，都是 Survivor 区大小分配不合理，可以同时进行优化。核心思想就是合理分配新生代老年代内存比例大小。

如图调整内存比例，线程运行每秒产生 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。

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

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

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

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

一次业务的时长，即一次请求的耗时。

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

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

部署多少台机器，每台机器配置如何。