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

在阿里云技术面终面的时候被问到这么一个问题：假设一个每天 100 万次登陆请求的平台，一个服务节点 8G 内存，该如何设置JVM参数？

下面以面试题的形式给大家梳理出来，做到一箭双雕：既供大家实操参考，又供大家面试参考。

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

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

第一步、新系统上线如何规划容量？

1. 套路总结

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

• 计算业务系统每秒钟创建的对象会佔用多大的内存空间，然后计算集群下的每个系统每秒的内存佔用空间（对象创建速度）；

• 设置一个机器配置，估算新生代的空间，比较不同新生代大小之下，多久触发一次 MinorGC；

• 为了避免频繁 GC，就可以重新估算需要多少机器配置，部署多少台机器，给 JVM 多大内存空间，新生代多大空间；

• 根据这套配置，基本可以推算出整个系统的运行模型，每秒创建多少对象，1 秒以后成为垃圾，系统运行多久新生代会触发一次 GC，频率多高。

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

有些同学看到这些步骤还是发憷，说的好像是那么回事，一到实际项目中到底怎么做我还是不知道。光说不练假把式，以登录系统为例模拟一下推演过程：

• 假设每天 100 万次登陆请求，登陆峰值在早上，预估峰值时期每秒 100 次登陆请求；

• 假设部署 3 台服务器，每台机器每秒处理 30 次登陆请求。假设一个登陆请求需要处理 1 秒钟，JVM 新生代里每秒就要生成 30 个登陆对象，1 秒之后请求完毕这些对象成为了垃圾；

• 一个登陆请求对象假设 20 个字段，一个对象估算 500 字节，30 个登陆佔用大约 15kb。考虑到 RPC 和 DB 操作，网络通信、写库、写缓存一顿操作下来，可以扩大到 20-50 倍，大约 1 秒产生几百 K～1M 数据；

• 假设 2C4G 机器部署，分配 2G 堆内存，新生代则只有几百 M，按照 1M/s 的垃圾产生速度，几百秒就会触发一次 MinorGC 了；

• 假设 4C8G 机器部署，分配 4G 堆内存，新生代分配 2G，如此需要几个小时才会触发一次 MinorGC。

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

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

第二步、如何进行垃圾回收器的选择

吞吐量还是响应时间？

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

吞吐量 = CPU在用户应用程序运行的时间 / （CPU在用户应用程序运行的时间 + CPU垃圾回收的时间）
响应时间 = 平均每次的GC的耗时

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

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

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

垃圾回收器设计上的考量

• JVM 在 GC 时不允许一边垃圾回收，一边还创建新对象（就像不能一边打扫卫生，还在一边扔垃圾）；

• JVM 需要一段 Stop the world 的暂停时间，而 STW 会造成系统短暂停顿不能处理任何请求；

• 新生代收集频率高，性能优先，常用复制算法；老年代频次低，空间敏感，避免复制方式；

• 所有垃圾回收器的涉及目标都是要让 GC 频率更少，时间更短，减少 GC 对系统影响。

CMS 和 G1

目前主流的垃圾回收器配置是新生代采用 ParNew，老年代采用 CMS 组合的方式，或者是完全采用 G1 回收器。从未来的趋势来看，G1 是官方维护和更为推崇的垃圾回收器。

业务系统：延迟敏感的推荐 CMS，大内存服务，要求高吞吐的，采用 G1 回收器。

CMS 垃圾回收器的工作机制

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

• 优点：并发收集、主打 “低延时” 。在最耗时的两个阶段都没有发生 STW，而需要 STW 的阶段都以很快速度完成；

• 缺点：消耗 CPU，浮动垃圾，内存碎片；

• 适用场景：重视服务器响应速度，要求系统停顿时间最短。