好难~记录一次生产上的OOM解决过程
点击上方，轻松关注！及时获取有趣有料的技术文章
记录一次生产上的OOM解决过程
一.项目架构
SpringCloud Dalston.SR1 + SpringBoot 1.5.9 + Mysql +Redis + RabbitMQ
所有的业务模块的应用服务都部署在同一个服务器，且单实例部署，服务器配置4核32G。
二. 原因分析
自己所负责的data模块这两天OOM较多，导致服务重启；
data服务主要业务是报表相关，数仓对接的业务以及多个外部数据相关的小程序的后台，与数据库的交互比较多，业务逻辑相对其他模块较为简单，
第一次：2月25日OOM情况:
由于Redis反序列化失败导致的OOM
第二次：2月26日的OOM情况:
由于GC无法回收对象导致
第一次发生OOM时，觉得可能就是由于Redis序列化器和反序列化器不一致，原有的JVM参数仅设置时-Xmx:512m -Xms:512m, 老年代：年轻代=2：1 ，老年代大概分配有300M内存
时候排查问题时，发现Redis的使用都是用自己用RedisTemplate封装的工具类，按道理说不会出现什么问题，并未过多关注；
第二次发生OOM时，与第一次相距的时间仅为1天，当时就觉得问题不对了，
1.首先使用jmap -histo:live pid 查看 服务内存活的对象，发现 [C 类型的数组和ConcurrentHashMap对象都存活较多；
检查代码后发现并未有显示的使用该两类类型，怀疑时是String字符串过多导致的；
2.其次使用JDK自带的分析工具：jmap -dump:format=b,file=文件名 [pid] 导出OOM时的dump日志；
导出时间非常慢，且占用线上系统的CPU，导致CPU达到100%
3.使用jstat -gc pid /jstat -gcutil pid 查看gc的状况
发现gc和fgc的都非常多，特别是fgc已经达到1000多次；
初步解决方案:（2月26日）
最后仍然是重启服务，-添加参数Xmx1024m -Xms:1024m
然后添加JVM参数（使用jinfo -flag可以在生产环境上直接添加）
jinfo -flag +HeapDumpBeforeFullGC pid
jinfo -flag +HeapDumpAfterFullGC pid
jinfo -flag +HeapDumpOnOutOfMemoryError pid
jinfo -flag +HeapDumpPath=/home/xxx/xxx pid 添加dump日志的目录（需要提前建好）
jinfo -flag -XX:+PrintGCDetails pid 开启gc日志
jinfo -flag -XX:+PrintGCDateStamps -Xloggc:/xxx/xxx 设置gc日志的目录
修改完成后第二天根据fgc产生的dump日志，加载到jvisualVM里面之后发现也是[C占用内存较多
下午 2点左右，监控线上服务时发现Old老年代的内存占用为300M，总大小为700M,经过一次FGC之后占用70M，这就比较正常了；
重点来了：
在2月26日添加完成JVM参数后，第二天同样的接口，FGC之前终于拿到了dump文件，大小是1.4G,接下来就是分析dump文件了，这里我选择了两个工具：
MAT与Jvisualvm
在使用体验来说JDK自带的Jvisualvm真的很垃圾，文件打开都要半个小时，果断放弃，转而使用MAT
导入dump文件以后如图
这里主要是看Leak Suspects：其他的几个指标在此也说明一下:
1. Histogram可以列出内存中的对象，对象的个数以及大小。
2. Dominator Tree可以列出那个线程，以及线程下面的那些对象占用的空间。
3.Top consumers通过图形列出最大的object。
4.Leak Suspects通过MA自动分析泄漏的原因。
打开Leak Suspects后可以看到线程堆栈如图
再继续找，找到是否有我们的业务代码。找到如图
这里其实已经定位到具体的业务代码了，但是MAT的强大之处就是可以定位究竟是什么大对象，
如图，这里已经可以看到了6W多个HashMap被Object[]引用，这里是内存占用的主要原因
OK，接下来可以看业务代码了
**
业务代码如下，只展示关键代码，这个接口是报表数据导出的接口，查询mysql后使用HashMap去接收结果集，
Object[]用于是用于写入报表工具类的入参；
查看服务器日志后，发现这条SQL有6W多条数据，而且在一分钟之内有人操作导出了两次，导致数据封装到HashMap里面，发生FGC
三、最终解决方案
1.加大堆内存 原来由512扩大到1024M；
2.HashMap改为JavaBean对象去封装结果集，因为HashMap底层是数组，还有其他的引用成员变量，更加有频繁的扩容，
查资料后发现HashMap在数据量的情况下内存占用比Java对象要大；
3.导出接口添加限流注解，防止在短时间内多次请求；
以下是限流代码:使用Guava的限流组件实现，当然也可以基于Redis的实现，或者自己实现一套
4.由于EasyExcel内存占用少，可以将poi换成阿里的EasyExcel，实现多条数据分页导出；
代码如下图片
代码如下
/**
* @author: Gabriel
* @date: 2020/2/18 12:03
* @description 自定义接口限流注解
*/
@Target({ElementType.TYPE,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface RateLimitAnno {
/** 每秒放入令牌桶中的token */
double limitNum() default 20;
}
/**
* @author: Gabriel
* @date: 2020/2/18 12:07
* @description
*/
@Slf4j
@Aspect
@Component
public class RateLimitAspect {
/**
* 用来存放不同接口的RateLimiter(key为接口名称，value为RateLimiter)
*/
private ConcurrentHashMap<String, RateLimiter> map = new ConcurrentHashMap<>();
private RateLimiter rateLimiter;
@Autowired
private static ObjectMapper objectMapper = new ObjectMapper();
@Autowired
private HttpServletResponse httpServletResponse;
@Pointcut("@annotation(com.gabriel.stage.annotation.RateLimitAnno)")
public void rateLimit() {
}
/**
* 环绕通知
*
* @param joinPoint
* @return
* @throws Exception
*/
@Around("rateLimit()")
public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
Object obj = null;
//获取拦截的方法签名
MethodSignature signature = (MethodSignature) joinPoint.getSignature();
Object target = joinPoint.getTarget();
//获取注解信息
Method method = target.getClass().getMethod(signature.getName(), signature.getParameterTypes());
RateLimitAnno annotation = method.getAnnotation(RateLimitAnno.class);
double limitNum = annotation.limitNum();
//获取方法名
String functionName = signature.getName();
//获取类名
String className = signature.getDeclaringTypeName();
signature.getDeclaringTypeName();
if (StringUtils.isNotBlank(className)) {
className = StringUtils.substringAfterLast(className, ".");
}
//拼接类名和方法名,保证key唯一
String joinName = StringUtils.join(functionName, className);
//获取rateLimiter
if (map.containsKey(joinName)) {
rateLimiter = map.get(joinName);
} else {
map.put(joinName, RateLimiter.create(limitNum));
rateLimiter = map.get(joinName);
}
if (rateLimiter.tryAcquire()) {
obj = joinPoint.proceed();
} else {
System.err.println("接口限流，请求降级。。。。。。。。。。。。。。。。。");
throw new BusinessException(ResultCode.SERVER_ERROR);
}
return obj;
}
作者：听风是雨
原文地址：https://www.cnblogs.com/july-sunny/p/12370615.html
上面就是本次文章的全部内容，感谢你的阅读，希望对你有帮助，也欢迎你点赞留言和转发~
关注我，不迷路，及时获取有趣有料内容，See you next good day~