JVM调优实战-从入门到入土！-CSDN博客

前言

JVM是现代Java应用的基石，其内部机制（内存模型、垃圾回收、即时编译）深刻影响着应用的吞吐量、延迟和资源利用率。-Xmx, -Xms, GC选择器、堆区划分... 这些看似简单的参数背后，蕴藏着巨大的性能优化空间。

每日上亿请求的电商系统JVM调优
1.背景引入
我们的背景是电商系统，电商系统其实一般会拆分成为很多的子系统独立部署，比如商品系统，订单系统，活动系统，数据统计系统，会员系统等。

这边就以订单系统来做例子
每日上亿请求，那么它会有多少活跃用户
一般每个用户平均访问20次，那么上亿大概有500W 日活跃
那么继续推算 500W 日活能有多少下单呢？
如果是10% 大概会有50W人下单，那么每天大概是50W订单
如果50W订单集中在4小时的高峰期内，那么平均每秒也才几十个订单，如果是几十个订单其实并不要过多去关注JVM，基本上每秒占用一些新生代得到内存，隔很久，新生代才会满，然后一次Minor GC 内存就出来了，没有啥压力
但是秒杀，大促销的场景就不这样了
如果是双11 基本上几分钟就会有几十万的订单，那么每秒的下单量可能是上千破万
抗住大促销需要几台机器
基本上3台机器可以了每个机器每秒300个下单部署的是4核8G
从本身来说这个硬件资源是够了扛住每秒300个问题不大
但是问题在于需要对JVM 有限的内存资源合理分配，让JVM GC次数减少，而且尽量避免Full GC
大促销订单系统的内存使用模型
基本上每秒处理300个下单来估算，其实因为下单涉及的接口请求是比较耗时的，所以呢每秒处理100到300是差不多的
那么每个订单的实体我的字段我按照1kb来算，单单300个订单就会有300kb的内存开销
然后算上一系列的其他业务对象就是放大10倍到20倍
此外，除了下单外还有很多跟订单相关的其他操作，比如查询这些我们再扩大10倍
那么每秒就是 300kb * 20 * 10=60MB的内存开销，这个内存开销会再1秒后可以是回收状态，如下图

由于资料篇幅较长，因此选择性地展示了部分内容。JVM资料整理花费了一年的零碎时间，希望能对大家学习有所帮助！有需要资料的伙伴篇末名片领取即可！

内存如何分配
假设我们是4核8G的机器，那么给到JVM 一般是4G，剩下的给操作系统来使用，其中堆内存我们可以给到3G，新生代给1.5G，老年代给1.5G
然后每个线程的Java虚拟机栈是1M,那么JVM如果有几百个线程大概是几百M
然后永生代给256内存，基本上4G差不多了

此时JVM的示意图如下

接下来就很明确了订单系统每秒大概300个订单，都是占据新生代60MB的内存，那么新生代大概是25秒中就会占满，如下图

25秒之后就会要进行Minor GC了，此时因为有-XX:HandlePromotionFailure选项，所以你可以认为需要进行的检查主要是比较老年代可用空间大小和历代Minor GC后进入老年代对象的平均大小，刚开始肯定这个检查是可以通过的
所以Minor GC直接运行，一下子可以回收掉99%的新生代对象，因为除了最近一秒的订单请求还在处理，大部分的订单早就处理完毕了，所以此时可能存活的对象也就是100MB
但是问题来了如果-XX:SuruvivorRatio 参数默认为8，那么此时Eden大概占用1.2GB内存，每个Surviuvor是150MB，如下图

然后再次运行20秒，把Eden区暂满，再次垃圾回收Eden和S1中的对象，存活对象可能还是100MB左右会进入S2,如下图

此时JVM参数如下

新生代垃圾回收优化之一：Survivor空间够不够
首先在进行JVM优化的时候，第一个要考虑的问题就是你通过估算，你的新生代的Survivor到底够不够
按照上面的逻辑首先每次新生代垃圾回收是100MB ，有可能会突破150MB，那么岂不是经常出现Minor GC过后无法放到Survivor中，那么岂不是会频繁进入到老年代？
还有，即使是Minor GC后的对象少于150MB，但是即使是100MB的对象进入了Survuvor区，因为这是一批相同年龄对象，直接超过了空间的50%，此时也可能会导致对象进入老年代
所以按这个模型来说，Surivor区域的空间明显是不够的
其实这里建议是把新生代调整为2G 老年代1G，那么此时Eden为1.6G，每个Survivor为200MB，如下图

这个时候，Survivor区域变大，就大大降低了新生代GC过后存活对象在Survivor里放下不下的问题，或者同龄对象超过50%的情况
这样就大大降低了新生代进入老年代的概率
此时JVM的参数如下

其实对于任何一个系统，首先类似上面的内存使用模型预估以及合理的分配内存，尽量让每次Minor GC后的对象都留着Survivor里，不要进入老年代，这个是你首先要优化的地方
新生代对象躲过多少次垃圾回收进入老年代
大家知道一个对象连续躲过15次垃圾回收会自动的进入老年代
其实按照上面的内存运行模型来说，基本上20秒触发一次Minor GC ,也就是一个对象再新生代几分钟还没回收，它就会进入老年代
有写博客说，要把参数设置高一点 20 30 ，其实这种说法是不对的
因为你对这个参数考虑必须结合系统的运行模型来说，如果躲过了15次GC 都几分钟，如果一个对象几分钟都不回收，肯定是系统里@Service这类注解
所以谁，考虑问题，一定不要人云亦云，要结合运行原理，自己推演和思考，不同的业务系统还都是不一样的
其实这个参数你也可以适当的降低它的值，比如说降到5次，也就是一个对象能够躲过5次Minor GC,在新生代超过1分钟，尽快让他进入老年代，别再新生代里面占着内存了
总之，这个参数必是结合你的系统具体运行模型来考虑的，此时JVM参数如下

多大的对象直接进入老年代？
另外一个逻辑就是说，大对象可以直接进入老年代，因为大对象说明是要长期存活和使用的
比如在JVM里可能会缓存一些数据，这个一般可以结合自己系统中到底有没有创建大对象来决定的
但是一般来说，这个给他设置1MB足够，因为很少有对象超过1MB的大对象，如果有，可能是你提前分配的，大List之类的
此时JVM的参数如下