启动Spring Boot时，如果不设置内存参数会如何？-技术圈

前言

最近正在进行从Spring Boot往Spring Cloud上改造升级。之前部署的应用程序比较少，还没什么问题。当Spring Cloud项目逐步新增之后，问题就爆发了，服务器内存不够用了。而现有的用户体量也没必要对服务器再次进行升级，于是就开始着手Spring Boot启动时JVM内存配置的优化。

服务现状

由于之前服务比较少，服务器资源充足，许多服务启动时都未添加JVM参数（遗留问题）。结果就是每个服务启动都占用了1.5G-2G的内存，有些服务的体量根本用不了这么多。那么，在Spring Boot中如果未设置JVM内存参数时，JVM内存是如何配置的呢？

JVM默认内存设置

当运行一个Spring Boot项目时，如果未设置JVM内存参数，Spring Boot默认会采用JVM自身默认的配置策略。在资源比较充足的情况下，开发者倒是不太用关心内存的设置。但一旦涉及到资源不足，JVM优化，那么就需要了解默认的JVM内存配置策略。

关于JVM内存最常见的设置为初始堆大小（-Xms）和最大堆内存（-Xmx）。很多人懒得去设置，而是采用JVM的默认值。特别是在开发环境下，如果启动的微服务比较多，内存会被撑爆。

而JVM默认内存配置策略分两种场景，大内存空间场景和小内存空间场景（小于192M）。

以4GB内存为例，初始堆内存大小和最大堆内存大小如下图：

默认情况下，最大堆内存占用物理内存的1/4，如果应用程序超过该上限，则会抛出OutOfMemoryError异常。初始堆内存大小为物理内存的1/64。

如果应用程序运行在手机上或物理内存小于192M时，JVM默认的初始堆内存大小和最大堆内存大小如下图：

最大堆内存为物理内存的1/2，初始堆内存大小为物理内存的1/64，但当初始堆内存最小为8MB，则为8MB。

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆到 -Xms的最小限制。因此，服务器一般设置-Xms、-Xmx相等以避免在每次GC后调整堆的大小。对象的堆内存由称为垃圾回收器的自动内存管理系统回收。

其中最大堆内存是JVM使用内存的上限，实际运行过程中使用多少便是多少。默认，分配给年轻代的最大空间量是堆总大小的三分之一。

针对最开始的问题，如果每个程序都按照默认配置启动，一台服务器上部署多个应用时，就会出现内存吃紧的情况，造成一定的浪费。最简单的操作就是在执行java -jar启动时添加上对应的jvm内存设置参数。

java -Xms64m -Xmx128m -jar xxx.jar

切记参数要防止-jar参数之前。否则会被当做系统参数而无效。

当然在排查JVM的使用情况时，还会用到以下相关操作。

查看系统默认内存设置

通过上面的描述我们可以看到，不同的系统配置，JVM使用的内存是不同的。我们可以通过Java命令自带的功能来查看默认的内存设置。

在Linux操作系统下，输入如下命令：

java -XX:+PrintFlagsFinal -version | grep HeapSize

在Windows操作系统下，输入如下命令：

java -XX:+PrintFlagsFinal -version | findstr HeapSize

查看运行时内存情况

当应用程序运行时，如果我们想查看程序的运行情况，可通过以下几种方式来查询不同维度的数据。

查看正在运行的jvm服务

可以通过jps命令查看正在运行的jvm服务。

appledeMacBook-Pro:~ apple$ jps51972 EurekaApplication51973 Launcher51976 Jps

其中前面的数字为进程号。

查看某进程的JVM情况

可以使用jstat命令查询具体进程的GC情况。

appledeMacBook-Pro:~ apple$ jstat -gc 51972 5000 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT14336.0 14336.0  0.0   14312.7 145920.0 100055.3  175104.0   17500.2   52136.0 48999.3 7600.0 6958.7      9    0.058   2      0.050    0.10714336.0 14336.0  0.0   14312.7 145920.0 100055.3  175104.0   17500.2   52136.0 48999.3 7600.0 6958.7      9    0.058   2      0.050    0.10714336.0 14336.0  0.0   14312.7 145920.0 100055.3  175104.0   17500.2   52136.0 48999.3 7600.0 6958.7      9    0.058   2      0.050    0.107

其中51972是进程号，5000为刷新时间。

对应数据项的含义：

S0C：年轻代中第一个survivor（幸存区）的容量 (字节)

S1C：年轻代中第二个survivor（幸存区）的容量 (字节)

S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)

S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)

EC：年轻代中Eden（伊甸园）的容量 (字节)

EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)

OC：Old代的容量 (字节)

OU：Old代目前已使用空间 (字节)

YGC：从应用程序启动到采样时年轻代中gc次数

YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)

FGC：从应用程序启动到采样时old代(全gc)gc次数

FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT：从应用程序启动到采样时gc用的总时间(s)

查看堆栈使用情况

通过jmap命令来查看堆栈的使用情况。

[root@bjb ~]# jmap -heap 10471Attaching to process ID 10471, please wait...Debugger attached successfully.Server compiler detected.JVM version is 25.262-b10
using thread-local object allocation.Parallel GC with 2 thread(s)
Heap Configuration:   MinHeapFreeRatio         = 0   MaxHeapFreeRatio         = 100   MaxHeapSize              = 2051014656 (1956.0MB)   NewSize                  = 42991616 (41.0MB)   MaxNewSize               = 683671552 (652.0MB)   OldSize                  = 87031808 (83.0MB)   NewRatio                 = 2   SurvivorRatio            = 8   MetaspaceSize            = 21807104 (20.796875MB)   CompressedClassSpaceSize = 1073741824 (1024.0MB)   MaxMetaspaceSize         = 17592186044415 MB   G1HeapRegionSize         = 0 (0.0MB)
Heap Usage:PS Young GenerationEden Space:   capacity = 342360064 (326.5MB)   used     = 128426952 (122.47748565673828MB)   free     = 213933112 (204.02251434326172MB)   37.51224675550943% usedFrom Space:   capacity = 4194304 (4.0MB)   used     = 3458288 (3.2980804443359375MB)   free     = 736016 (0.7019195556640625MB)   82.45201110839844% usedTo Space:   capacity = 4194304 (4.0MB)   used     = 0 (0.0MB)   free     = 4194304 (4.0MB)   0.0% usedPS Old Generation   capacity = 216006656 (206.0MB)   used     = 86142704 (82.15208435058594MB)   free     = 129863952 (123.84791564941406MB)   39.879652597371816% used
22325 interned Strings occupying 2361920 bytes.

关于具体参数就不在这里解释了。

小结

项目中往往一些被忽视的问题，深究起来，排查起来，反而能串联起来一系列的知识点和技能，或许这就是深入思考与探索的魅力所在。你在项目的使用过程中是否也遇到类似的问题，是否也深入探究过么？

往期推荐

因为一次宕机，终于搞透了 Kafka 高可用原理！

作为架构师，你知道前后端分离，有什么优缺点？

最常见的10种Java异常问题

大佬也hashcode方法上翻船了，不小心秀了一把！

不要再满屏写 try...catch 了！这个更香！

如果你觉得这篇文章不错，那么，下篇通常会更好。添加微信好友，可备注“加群”（微信号：zhuan2quan）。

一篇文章就看透技术本质的人，
和花一辈子都看不清的人，
注定是截然不同的搬砖生涯。

▲ 长按关注”程序新视界“，洞察技术内幕