关于JVM内存参数设置有一点想法，在这里记录一下：

JVM内存参数设置没有固定的设置，一般都是对系统的业务以及单个业务对象的数据大小有一个初步的预估后，结合实际的业务场景以及并发量，对JVM内存参数进行一个初步的设置，并根据系统的实际运行情况来不断地调整，最后达到最佳的参数配置。下面我就根据之前做做的一个活动协同配置中心的业务，给出一个我认为合理的JVM配置信息

针对营销活动推送中心的JVM参数配置

之前我做过的一个营服协同中心的核心业务就是对活动消息进行一个收转发，从各个信息采集系统中获取需要推送的消息以及目标客户，在某个固定的时间以短信、电话等方式进行活动消息推送。

• 业务规模：系统每天的推送消息总量在100万，即每天各外系统合计会调用100万次我们的消息接受接口，而且时间主要是晚上12点，在4个小时内完成推送
• 业务计算数据量：按次规模来算，4个小时，接受100万条消息数据，即每秒钟需要接受70条数据，每条消息的数据量不超过10KB
• JVM内存分配：
• 目前常用的机器配置一般是2核4G或者4核8G的配置，单个消息对象的大小不会超过50KB(消息体数据量是10KB，不过java对象还要附带其他的数据，所以预制的内存量需要乘以5)，即1秒钟需要占用新生代空间3.5M的内存。
• 如果只用的是2核4G的配置，扣减掉操作系统以及其他软件占用的1.5G内存、非堆空间占用1G内存，分配给堆空间的只剩下1G多的内存，而老年代需要存储一些spring等常用对象，至少需要600M的空间，给新生代只有500M左右，140秒左右新生代的内容就会触发一次minor gc，如此频繁的minor gc会导致 性能受损以及老年代空间迅速被堆积，导致full gc，此时系统性能就会有一个骤降，多次full gc后，会导致实际业务流转出现故障，因此针对此业务场景，需要采用4核8g的机器
• 使用4核8G的机器，JVM可用空间可达到6.5G，此时就可以做一些适应性的调整，我的jvm配置参数是这样：
• -Xms:2048m
• -Xmx:2048m
• -Xmn:1024m
• -XX:MetaspaceSize:256m
• -XX:MaxMetaspaceSize:256m
• 基于上述的配置，同时部署3台机器，则15分钟才会触发一次minor gc，就大大降低了新生代空间的数据迁移到老年代的可能性，从而极大的降低了触发full gc的可能性

以上就是我根据自己工作中用到的系统举得一个例子，不过此参数配置只是针对于消息收转发这一个业务，系统肯定会有很多其他的业务，只要根据上面给出的规则来，适当的增加机器就将full gc的几率降低到最好，最高性价比的保证系统的稳定性了。