小编给大家分享一下OOM问题排查的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
成都创新互联是一家集网站建设,东胜企业网站建设,东胜品牌网站建设,网站定制,东胜网站建设报价,网络营销,网络优化,东胜网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
运维反馈线上程序出现了OOM，程序日志中的输出为
Exception in thread "http-nio-8080-exec-1027" java.lang.OutOfMemoryError: Java heap space Exception in thread "http-nio-8080-exec-1031" java.lang.OutOfMemoryError: Java heap space
看线程名称应该是tomcat的nio工作线程，线程在处理程序的时候因为无法在堆中分配更多内存出现了OOM，幸好JVM启动参数配置了-XX:+HeapDumpOnOutOfMemoryError，使用MAT打开拿到的hprof文件进行分析。
第一步就是打开Histogram看看占用内存最大的是什么对象：
可以看到byte数组占用了接近JVM配置的最大堆的大小也就是8GB，显然这是OOM的原因。
第二步看一下究竟是哪些byte数组，数组是啥内容：
可以看到很明显这和HTTP请求相关，一个数组大概是10M的大小。
第三步通过查看GC根查看谁持有了数组的引用：
这符合之前的猜测，是tomcat的线程在处理过程中分配了10M的buffer在堆上。至此，马上可以想到一定是什么参数设置的不合理导致了这种情况，一般而言tomcat不可能为每一个请求分配如此大的buffer。
第四步就是检查代码里是否有tomcat或服务器相关配置，看到有这么一个配置：
max-http-header-size: 10000000
至此，基本已经确定了八九不离十就是这个不合理的最大http请求头参数导致的问题。
到这里还有3个疑问：
即使一个请求分配10M内存，堆有8GB，难道当时有这么多并发吗？800个tomcat线程？
参数只是设置了最大请求头10M，为什么tomcat就会一次性分配这么大的buffer呢？
为什么会有如此多的tomcat线程？感觉程序没这么多并发。
先来看问题1，这个可以通过MAT在dump中继续寻找答案。
可以打开线程视图，搜索一下tomcat的工作线程，发现线程数量的确很多有401个，但是也只是800的一半：
再回到那些大数组的清单，按照堆分配大小排序，往下看：
可以发现除了有10008192字节的数组还有10000000字节的数组，查看引用路径可以看到这个正好是10M的数组是output buffer，区别于之前看到的input buffer：
好吧，这就对了，一个线程分配了输入输出两个buffer，占用20M内存，一共401个线程，占用8GB，所以OOM了。
还引申出一个问题为啥有这么多工作线程，
再来看看问题2，这就需要来找一下源码了，首先max-http-header-size是springboot定义的参数，查看springboot代码可以看到这个参数对于tomcat设置的是MaxHttpHeaderSize：
然后来看看tomcat源码：
进一步看一下input buffer：
buffer大小是MaxHttpHeaderSize+ReadBuffer大小，这个默认是8192字节：
