我们以一个每日百万级别的交易支付系统作为背景，来分析一下，在线上部署一个系统时，应该如何根据系统的业务来合理的设置JVM对内存的大小。
系统整体架构
支付订单
1、上述业务流程中，最核心的环节是在用户发起支付请求的时候，会生成一个支付订单
2、这个支付订单需要记录几个核心要素：
-谁发起的支付？
-对那个商品的支付？
-通过那个渠道进行的支付？
-支付的时间
等等诸如此类的信息
如果每日有百万笔交易，在JVM的角度来看，就是每天会在JVM中创建上百万个新的支付订单对象
1、假设每天有100万个支付订单一般用户交易行为会集中在几个小时内的高峰期中。
2、对于高峰期而言，每秒需要能够支持处理100笔订单左右。
3、假设我们的支付系统部署了3台机器，每台机器实际上每秒需要处理30笔订单。
支付订单需求
1、一次支付请求，需要在JVM中创建一个支付订单对象，填充数据，然后办这个支付订单写入数据库，进行付款等等。
2、假设一次支付请求的处理，从头到尾，总共大概需要1秒的时间。
3、那么对于每台机器而言，一秒钟接受到30笔支付的请求，然后在JVM的新生代理创建了30 个支付订单对象。
4、1秒钟之后，对这30个支付订单进行处理，就可以对它们的引用进行回收，这些订单对象就成为JVM新生代里面，没人引用的垃圾对象了。
支付对象大小：
1、直接根据支付订单类中的实例变量的类型来计算，比如：
-Integer类型的变量数据是4个字节
-Long类型变量数据是8个字节
2、一般来说，支付订单这种核心累呢，按照20-30个实例变量来计算，一个对象大概也就是在1kb左右。
3、对于一台机器来说，每秒钟处理30笔支付订单的请求，大概占据的空间最多就是30*1kb而已。
运行过程
1、但是真实的支付系统在运行过程中，肯定每秒还会创建大量的其他对象。我们估算一下，每秒钟除了支付订单对象，还会创建其他对象
2、对于30个订单对象，需要30*1KB=30KB的内存空间，算上其他对象，那么每秒钟创建出来的对象，一共大概需要接近1MB左右。
3、然后下一秒，对新的请求继续创建大概1MB左右的对象，放在新生代里面。
4、循环多次后，新生代垃圾太多，就会触发Minor GC回收掉这些垃圾。
JVM堆内存设置
核心目的：减少Minor GC的出现。
1.其实一般来说线上业务系统，常见的机器配置是2核4G，或者是4核8G
2.如果用2核4G的机器来部署，机器4G内存，JVM进程估计最多也就是2G内存。
3.这2G还得分给元空间、栈内存、堆内存几块区域，那么堆内存估计可能也就1个多G的内存空间。堆内存还分为新生代和老年代，那么新生代可能也就几百MB的内存
4.整个系统每秒需要1MB左右的内存空间，新生代只有几百MB，运行几百秒也就是大概五六分钟左右，新生代内存空间就满了，肯定会触发Minor GC。如果这么频繁的触发Minor GC，必然会影响线上系统的性能稳定性