阿里面试：每天100w次登陆请求, 8G 内存该如何设置JVM参数？

上周知识星球的同学在阿里云技术面终面的时候被问到这么一个问题：假设一个每天100w次登陆请求的平台，一个服务节点 8G 内存，该如何设置JVM参数？ 觉得回答的不太理想，过来找我复盘。

下面以面试题的形式给大家梳理出来，做到一箭双雕：

• 既供大家实操参考
• 又供大家面试参考

大家要学习的，除了 JVM 配置方案 之外，是其 分析问题的思路、思考问题的视角。 这些思路和视角，能帮助大家走更远、更远。

接下来，进入正题。

每天100w次登陆请求, 8G 内存该如何设置JVM参数？

每天100w次登陆请求, 8G 内存该如何设置JVM参数，大概可以分为以下8个步骤。

Step1：新系统上线如何规划容量？

1.套路总结

任何新的业务系统在上线以前都需要去估算服务器配置和JVM的内存参数，这个容量与资源规划并不仅仅是系统架构师的随意估算的，需要根据系统所在业务场景去估算，推断出来一个系统运行模型，评估JVM性能和GC频率等等指标。以下是我结合大牛经验以及自身实践来总结出来的一个建模步骤：

• 计算业务系统每秒钟创建的对象会佔用多大的内存空间，然后计算集群下的每个系统每秒的内存佔用空间（对象创建速度）
• 设置一个机器配置，估算新生代的空间，比较不同新生代大小之下，多久触发一次MinorGC。
• 为了避免频繁GC，就可以重新估算需要多少机器配置，部署多少台机器，给JVM多大内存空间，新生代多大空间。
• 根据这套配置，基本可以推算出整个系统的运行模型，每秒创建多少对象，1s以后成为垃圾，系统运行多久新生代会触发一次GC，频率多高。

2.套路实战——以登录系统为例

有些同学看到这些步骤还是发憷，说的好像是那么回事，一到实际项目中到底怎麽做我还是不知道！

光说不练假把式，以登录系统为例模拟一下推演过程：

• 假设每天100w次登陆请求，登陆峰值在早上，预估峰值时期每秒100次登陆请求。
• 假设部署3台服务器，每台机器每秒处理30次登陆请求，假设一个登陆请求需要处理1秒钟，JVM新生代里每秒就要生成30个登陆对象，1s之后请求完毕这些对象成为了垃圾。
• 一个登陆请求对象假设20个字段，一个对象估算500字节，30个登陆佔用大约15kb，考虑到RPC和DB操作，网络通信、写库、写缓存一顿操作下来，可以扩大到20-50倍，大约1s产生几百k-1M数据。
• 假设2C4G机器部署，分配2G堆内存，新生代则只有几百M，按照1s1M的垃圾产生速度，几百秒就会触发一次MinorGC了。
• 假设4C8G机器部署，分配4G堆内存，新生代分配2G，如此需要几个小时才会触发一次MinorGC。

所以，可以粗略的推断出来一个每天100w次请求的登录系统，按照4C8G的3实例集群配置，分配4G堆内存、2G新生代的JVM，可以保障系统的一个正常负载。

基本上把一个新系统的资源评估了出来，所以搭建新系统要每个实例需要多少容量多少配置，集群配置多少个实例等等这些，并不是拍拍脑袋和胸脯就可以决定的下来的。

Step2：该如何进行垃圾回收器的选择？

吞吐量还是响应时间

首先引入两个概念：吞吐量和低延迟

吞吐量 = CPU在用户应用程序运行的时间 / （CPU在用户应用程序运行的时间 + CPU垃圾回收的时间）

响应时间 = 平均每次的GC的耗时

通常，吞吐优先还是响应优先这个在JVM中是一个两难之选。

堆内存增大，gc一次能处理的数量变大，吞吐量大；但是gc一次的时间会变长，导致后面排队的线程等待时间变长；相反，如果堆内存小，gc一次时间短，排队等待的线程等待时间变短，延迟减少，但一次请求的数量变小（并不绝对符合）。

无法同时兼顾，是吞吐优先还是响应优先，这是一个需要权衡的问题。

垃圾回收器设计上的考量

• JVM在GC时不允许一边垃圾回收，一边还创建新对象（就像不能一边打扫卫生，还在一边扔垃圾）。
• JVM需要一段Stop the world的暂停时间，而STW会造成系统短暂停顿不能处理任何请求；
• 新生代收集频率高，性能优先，常用复制算法；老年代频次低，空间敏感，避免复制方式。
• 所有垃圾回收器的涉及目标都是要让GC频率更少，时间更短，减少GC对系统影响！

CMS和G1

目前主流的垃圾回收器配置是新生代采用ParNew，老年代采用CMS组合的方式，或者是完全采用G1回收器，

从未来的趋势来看，G1是官方维护和更为推崇的垃圾回收器。

关注公众号：码猿技术专栏，回复关键词:1111 获取阿里内部Java性能调优手册！

业务系统:

• 延迟敏感的推荐CMS；
• 大内存服务，要求高吞吐的，采用G1回收器！

CMS垃圾回收器的工作机制

CMS主要是针对老年代的回收器，老年代是标记-清除，默认会在一次FullGC算法后做整理算法，清理内存碎片。

CMS GC	描述	Stop the world	速度
1.开始标记	初始标记仅标记GCRoots能直接关联到的对象，速度很快	Yes	很快
2.并发标记	并发标记阶段就是进行GCRoots Tracing的过程	No	慢
3.重新标记	重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。	Yes	很快
4.垃圾回收	并发清理垃圾对象(标记清除算法)	No	慢

• 优点：并发收集、主打“低延时” 。在最耗时的两个阶段都没有发生STW࿰