现象：

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

分析：

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

尝试解决问题的步骤：

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

HTTP/1.1 200 
Access-Control-Allow-Origin: *
Access-Contr

• 1
• 2
• 3

选其中的一个，选择显示最近的垃圾回收根节点
https://img-blog.csdnimg.cn/img_convert/058882cd60347a1162c9063a75d364b0.png
看到持有这个byte[]对象的是一个 HeapByteBuffer对象，HeapByteBuffer是java NIO中的对象。

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

于是先去项目中找到如下相关配置：
https://img-blog.csdnimg.cn/img_convert/eee4199b4671ce33f2f8e870866f7227.png

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

问题总结:

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