内存空间不足

前言：

这个模块主要是记录生产线上出现的问题，虽然内心是拒绝创建这个模块的，但是谁又能保证自己的应用在线上一定不会出现问题呢，在这里呢也做个记录，方便以后不再犯同样的问题。

背景情况

本人负责的几个应用，之前线上部署的是虚拟机，后来公司统一使用docker容器来代替虚拟机，故应用需要做升级改造，之前设置的一些jvm参数都失效了，我记得那是第一次容器发布后的第三天，钉钉收到告警，线上集群机器内存空间不足(线上设置告警，当可用空间不足20%就会告警)

处理过程

收到告警后，第一时间马上登录线上机器执行相关命令
指令：jstat -gc [pid] //pid为进程号

图片中命令后有个5000，表示每隔5秒打印一次，可以看到出现了很多参数，在文章结尾会对这些参数做相关介绍，我们这里主要观察是的是S0C+S1C+EC的情况，这个是年轻代的大小，可以发现者目前年轻代占了4.8G，快到5G了，再加上系统自身运行的内存等等，很容易到达内存的告警值(线上内存8G，告警值为超过80%)，故修改一台机器的内存指为4G，-Xmx为4G(运行过程中，最大分配内存)，当然也可以设置-Xmn，年轻代大小，观察线上运行情况

可以发现，内存基本趋于稳定，并没有高出告警值，查看下相关命令
指令：jstat -gcutil [pid]

可以发现FGC，老年代触发的次数有8次，这个相对应用来说，还是有点高的，故吧内存dump下来，查看具体情况，
dump指令：jmap -dump:file=文件名.dump [pid] //生成对应的dump文件
或者：jmap -dump:format=b,file=xxx pid
然后用Memory Analyzer打开dump文件进行分析

指令相关参数介绍

S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
PC：Perm(持久代)的容量 (字节)
PU：Perm(持久代)目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
NGCMN：年轻代(young)中初始化(最小)的大小 (字节)
NGCMX：年轻代(young)的最大容量 (字节)
NGC：年轻代(young)中当前的容量 (字节)
OGCMN：old代中初始化(最小)的大小 (字节)
OGCMX：old代的最大容量 (字节)
OGC：old代当前新生成的容量 (字节)
PGCMN：perm代中初始化(最小)的大小 (字节)
PGCMX：perm代的最大容量 (字节)
PGC：perm代当前新生成的容量 (字节)
S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E：年轻代中Eden（伊甸园）已使用的占当前容量百分比
O：old代已使用的占当前容量百分比
P：perm代已使用的占当前容量百分比
S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)
S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节)
ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)
DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）
TT： 持有次数限制
MTT ： 最大持有次数限制

JVM相关参数

-Xmx：设置运行时最大可用内存
-Xms：设置J初始内存大小，可于Xmx一致，以避免每次垃圾回收完成后重新分配内存
-Xmn：设置年轻代大小
-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4