记录一次发生的OOM异常,OutOfMemoryError: Java heap space

背景

  • 平台上传图片列表压缩文件,大小87M,耗时44s,然后报了500异常。
  • 随后查看后端日志,发现报OutOfMemoryError: Java heap space,但是数据却成功完全添加到mysql中了,特别奇怪。

分析原因

  • 流程:前端解析压缩文件转化为image-base64的json数据 =》传给后端 =》后端解析入mysql。
  • 通过分析OOM日志,发现是AOP切面类往mysql插入操作日志时产生的OOM异常。
  • 但是内存只多了大约100M数据(图片文件转base64后会变大),难道就真的差这100M数据就达到极限吗?查看JVM进程信息,堆内存给的1G,确实有点小,但是这个服务本身就属于配置类的服务,也应该够用了。
  • 后面发现同时还存在一个定时任务,每隔10s就要从mysql中取一次图片base64数据,原因应该就是image-base64数据刚插入mysql,随之定时任务就执行了,将刚插入的数据又拿到内存中,此时瞬间占用将近200M内存
  • 具体报错位置是JSON.toJSONString()方法,操作日志会保存body体参数,当序列化body体参数时,系统直接崩溃了。

解决

1、堆内存增加到2G。

2、限制body体大小。

  • 正常情况改SpringBoot的一个配置(server.tomcat.max-http-post-size: 100MB)就行了,但是在SpringBoot 2.4.0版本之后,该配置就被移除了。
  • 只留下server.tomcat.max-http-form-post-size=2MB(这个专门限制application/x-www-form-urlencoded表单提交的形式)、server.tomcat.max-swallow-size=2MB(这个表示当超出限制便不再读取了,避免内存溢出)、spring.servlet.multipart.max-request-size=2MB(这个专门限制multipart/form-data文件上传),但是此时请求是application/json类型,所以这几个都不能用。
  • 最后只能写一个filter来限制了。

3、json序列化时忽略不必要的参数。

  • 像image-base64这类数据根本没必要存,所以直接忽略。
  • @JSONField(serialize = false, deserialize = false),仅作用于FastJSON,并且不影响ORM框架。
  • private transient String imageBese64,作用于FastJSON/Gson/Jackson/输入输出流等,不影响ORM框架。
相关推荐
27669582921 小时前
tiktok 弹幕 逆向分析
java·python·tiktok·tiktok弹幕·tiktok弹幕逆向分析·a-bogus·x-gnarly
用户40315986396631 小时前
多窗口事件分发系统
java·算法
用户40315986396631 小时前
ARP 缓存与报文转发模拟
java·算法
小林ixn1 小时前
大一新手小白跟黑马学习的第一个图形化项目:拼图小游戏(java)
java
nbsaas-boot1 小时前
Go语言生态成熟度分析:为何Go还无法像Java那样实现注解式框架?
java·开发语言·golang
hi0_61 小时前
03 数组 VS 链表
java·数据结构·c++·笔记·算法·链表
朝如青丝暮成雪_2 小时前
java的三大特征
java
用户0595661192092 小时前
Java 8 + 特性与 spring Boot 及 hibernate 等最新技术实操内容全解析
java·架构·设计
长安有故里y2 小时前
tomcat设置预防host头攻击
java·tomcat·firefox
生产队队长2 小时前
Tomcat问题:启动脚本startup.bat中文乱码问题解决
java·ajax·tomcat