【经验分享】OOM故障分析记录:byte[] 占用了大量内存

2022/1/24 7:04:28

本文主要是介绍【经验分享】OOM故障分析记录:byte[] 占用了大量内存,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

现象:

工作时遇到某个服务老是频繁重启,日志报错为OOM

分析:

出现OOM是因为整个堆内存不够用了,此时JVM首先尝试扩展更多的空间,其次GC尝试回收内存,前两种方法无果的情况下只能报OOM并退出
可能的情况:内存不够、内存泄漏

尝试解决问题的步骤:

  1. 加上JVM参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath= ,设置当出现OOM时,dump整个堆的信息
  2. 等OOM后,将文件拷贝到电脑上
  3. 用JDK自带的 visualVM,打开dump文件
    设置了最大堆大小 512M,从下图看出,确实占满了导致OOM
    20191122170147350.png
  4. 转到类实例占用大小视图,找到占用最大的类
    image.png
    可以看到,总共512M堆大小,byte[]对象占用了其中的90%,这显然是异常占用
    接下来转到实例视图,查看具体的实例
    image.png
    最大的byte[]对象占用了 约 10M
    拷贝byte[]对象中存储的内容,并在代码中构建byte[]对象存入String打印出可视化内容
    image.png
    打印出的部分String内容如下,可以看到存储的是 http header的内容,并且byte[]中99%的内容为0,说明大量空间并未被使用到
HTTP/1.1 200 
Access-Control-Allow-Origin: *
Access-Contr

选其中的一个,选择显示最近的垃圾回收根节点
image.png
看到持有这个byte[]对象的是一个 HeapByteBuffer对象,HeapByteBuffer是java NIO中的对象。

程序中没有使用NIO,推测NIO应该在Tomcat中被使用,并且Tomcat的默认配置不可能为 10M这么不合理的值,那感觉可能是有不合理的自定义配置存在。

于是先去项目中找到如下相关配置:
image.png

发现,Tomcat中最大请求头大小被设置为 10M,和刚才byte[]对象占用的大小相似(多出的应为对象头以及其他多申请的空间,具体要参考源码),其次也和前面发现的byte[]对象中存储的是请求头信息的事实相符合,这应该就是问题所在,把这个配置调小点或者干脆使用默认配置即可。

问题总结:

咨询了相关同事,为了传输较大的文件,调大了 tomcat max-http-post-size,顺手改了 max-http-header-size,容器初始化处理请求的线程池时,每个线程都会申请 此处为 10M大小的byte[]对象,并且请求处理线程的生命周期一般和服务的生命周期一致,也就是说,线程持有的 byte[]对象在整个服务周期中是一直存活的。一般线程池的规模少说也在几十个,也意味着服务正常工作时,几百兆的堆内存(也可能是堆外内存,具体看Tomcat配置使用哪个)会被请求处理线程一直占用,当分配的内存较少时,很快OOM

转载:一次OOM故障分析记录:HeapByteBuffer byte[] 占用了大量内存



这篇关于【经验分享】OOM故障分析记录:byte[] 占用了大量内存的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程