Tomcat OOM问题排查：巨额HTTP头导致内存溢出

"一次在线应用程序的OOM(Out Of Memory)问题排查和解决的实践案例" 在本次事件中，线上程序遇到了由Java虚拟机(JVM)内存溢出引发的故障。问题表现为Tomcat应用服务器的NIO工作线程抛出了`OutOfMemoryError: Java heap space`异常。这种异常通常意味着Java堆内存不足以分配新的对象。幸运的是，JVM在出现OOM时被配置为生成堆转储文件(-XX:+HeapDumpOnOutOfMemoryError)，这为问题的诊断提供了关键数据。 首先，通过内存分析工具MAT(Memory Analyzer Tool)对生成的hprof文件进行分析。在Histogram视图中，发现byte数组占据了接近JVM最大堆大小（8GB）的内存，这是导致OOM的主要原因。 进一步的调查揭示了这些大型byte数组与HTTP请求相关，每个数组大约有10MB。接着，通过GC Roots分析，确认是Tomcat的线程在处理请求时在堆上分配了这些大缓冲区。这提示可能存在配置问题，即Tomcat可能为每个请求分配了过大的内存缓冲。 在代码或服务器配置中找到了`max-http-header-size: 10000000`，这表示允许的最大HTTP头部尺寸为10MB。问题的症结很可能就在这里：一个不合理的最大HTTP请求头大小设置导致了大量内存被消耗。 尽管如此，还有三个疑问待解： 1. 如果每个请求仅分配10MB内存，即使堆有8GB，为何会出现这么多并发的OOM错误？需要800个Tomcat线程吗？ 2. 参数设置的最大请求头为10MB，为何Tomcat会一次性分配如此大的缓冲？ 3. 为什么存在这么多Tomcat线程？这似乎超出了程序的并发需求。 对于问题1，MAT的线程视图显示了401个Tomcat工作线程，虽然数量较大，但并未达到800。继续深入分析大数组列表，发现在10008192字节的数组之外，还有一个10000000字节的数组。通过引用路径，发现这个大小与设置的最大HTTP头部大小相匹配。 这表明可能存在某种情况，使得Tomcat在处理特定请求时，基于配置的最大值一次性创建了大缓冲区。至于为何线程数量超出预期，可能的原因包括并发请求模式、Tomcat的线程池配置或其他系统因素。为了解决这个问题，需要调整`max-http-header-size`设置，并可能需要优化Tomcat的线程池配置，以确保其适应实际的并发需求，避免过多内存消耗。 总结来说，这次问题排查展示了对Java内存问题的典型处理步骤，包括理解日志错误、分析内存转储、查找内存占用大户、追踪GC根以及审查代码和配置。这强调了监控和优化JVM内存设置的重要性，以及在遇到性能问题时采用系统性方法来诊断和解决问题的必要性。