JVM系统优化实践（4）以支付系统为例

　　您好，我是湘王，这是我的头条号「湘王说」，欢迎您来，欢迎您再来～
　　前面说过，JVM会将堆内存划分为年轻代、老年代两个区域。年轻代会将创建和使用完之后马上就要回收的对象放在里面，而老年代则将创建之后需要长期存在的对象放在里面。那么现在再来看一个比较具体的例子。
　　在电商系统中，支付系统大概处于这样的位置：
　　核心业务流程是：
　　假设日活在100W，那么JVM会创建和销毁100万个支付订单。那么问题来了：
　　1、需要部署多少台机器？
　　2、每台机器需要多大内存？
　　3、每台机器上启动的JVM需要分配多大堆内存空间？
　　4、JVM需要分配多大内存空间才能保证不会崩溃？
　　假设现在面试官坐在你对面，这灵魂四连问，你该怎么回答？
　　所以，需要合理地设置JVM堆参数，依据是：
　　首先要明确的，就是每秒钟要处理多少笔订单，这里是100万笔，那么：
　　1、每天100万单，都分别在两个高峰期：中午和下班后，每个高峰持续2小时，就是：2 × 2 = 4小时；
　　2、4小时 = 4 × 3600 = 14400秒；
　　3、100万 ÷ 14400秒 = 69.4单/秒，将系统性能弄紧凑一些，可以按150单/秒算；
　　4、假设支付系统部署了3台机器，且采取流量均分策略，那么每台机器至少每秒需要处理50个订单：支付订单请求 -> JVM创建支付订单对象 -> 写入数据库 -> 处理其他事务 -> 返回数据（不含网络请求时间损耗），假设理想状态下需要花费20毫秒时间，那么：
　　l 接收到50笔支付订单请求 -> 在JVM年轻代中创建50个订单支付对象 -> 50 × 20毫秒=1秒之后处理完毕
　　l JVM将引用收回，这些对象就成了年轻代中的垃圾对象
　　l 下一秒继续重复上述过程
　　5、每笔支付订单所需的内存空间，依据实例对象及变量类型计算：
　　l 每个实例对象的Java基本类型所占据的空间 + 引用对象所占据的空间 ≈ 1KB；
　　l 50笔支付订单 = 50K内存空间；
　　6、JVM中的对象创建持续累积：
　　按照每秒消耗50KB的速度，如果没有垃圾回收，那么一台内存8G的机器大概会经过46个小时之后，将内存耗尽（8 × 1024 × 1024K = 8388608 / 50 = 167772 秒 / 3600 = 46小时）；
　　服务器肯定不会将全部内存给应用运行，最多20%~40%，资源实际耗尽时间更短；
　　此时，垃圾回收出现，清场，腾位置，应用继续运行，这个过程循环往复；
　　7、真实的系统资源消耗，会比理想条件下的预估高出20倍以上。
　　所以，这里给出建议的配置方案：
　　1、无脑化通用配置：2C4G/4C8G；
　　2、建议有条件，只考虑4C8G及以上（硬件成本还会继续下降）；
　　3、单台：-Xms3072M -Xmx3072M -Xmn2048M；
　　4、如果业务量更大，可以不只部署3台，可以是5台，10台或更多。
　　大促期间，访问量暴增10~100倍，因为压力骤增，部分请求出现超时甚至卡死、挂掉。这部分特别慢且未被释放的请求，可能会被GC误移入老年代，导致老年代里也出现越来越多的垃圾对象，由此：
　　年轻代资源不足 -> 年轻代频繁GC -> 老年代资源不足 -> 老年代频繁GC
　　依据经验，一般情况下：
　　JVM栈上线初期：512K~1M足够
　　永久代上线初期：512M~1G足够
　　FAQ：
　　1、方法执行完后，栈帧立马出栈，因此该栈帧中的变量等数据立即就被回收了；
　　2、项目中托管给Spring管理的对象，带@Configration的都是长期存在于老年代；
　　3、自定义的bean对象如果不被定义为类对象就是朝生夕灭的，分配在年轻代中；
　　4、内存不够才会回收软引用对象，内存空间足够的话，不会回收软引用对象；
　　5、弱引用不管内存空间够不够，只能撑到下次垃圾回收之前，就被会回收；
　　6、垃圾回收的是软引用，弱应用和虚引用；
　　7、并不是新生代全部占满才minor gc，而是只要里面一块主要的内存区域满了就minor gc；
　　8、通过合理的估算方式尽量设大新生代 ，让系统在高峰期不进行垃圾回收。
　　感谢您的大驾光临！咨询技术、产品、运营和管理相关问题，请关注后留言。欢迎骚扰，不胜荣幸～
　　我在头条