Java OOM问题排查：从异常到解决方案

"一次线上出现的OOM问题排查案例分享，涵盖了从问题发现到解决的全过程，主要涉及Java堆内存溢出、Tomcat NIO工作线程、内存分析工具MAT的使用，以及异常处理和配置检查。" 在Java应用程序中，OutOfMemoryError（OOM）是一个常见的运行时错误，通常表明内存资源耗尽。本篇实战记录讲述了如何排查一次由Java堆内存溢出（Java Heap Space）引发的OOM问题。问题起始于运维人员反馈的线上程序异常，日志显示多个HTTP-NIO工作线程在处理请求时遇到Java堆空间不足的情况。 首先，利用JVM的-XX:+HeapDumpOnOutOfMemoryError选项生成的hprof文件，通过Eclipse Memory Analyzer Tool (MAT) 进行内存分析。在Histogram视图中，发现byte数组占据了近8GB的内存，远超JVM的最大堆大小，这是引发OOM的主要原因。 进一步分析发现，这些byte数组与HTTP请求相关，每个数组大约有10MB，这意味着可能是Tomcat在处理HTTP请求时分配了过大的内存缓冲区。通过GC Roots查看引用关系，确认了是Tomcat的线程在处理请求时创建了这些大数组。 接着，问题聚焦到代码中可能存在的配置问题，发现了一个配置项`max-http-header-size: 10000000`，这表示最大HTTP请求头的大小为10MB。这个配置很可能导致了Tomcat一次性分配大容量的缓冲区，从而触发了OOM。 然而，问题并未完全明朗，仍有三个疑问待解： 1. 如果每个请求分配10MB，为何会同时有那么多线程（约800个）遇到问题？ 2. 为何Tomcat会按照最大请求头大小一次性分配内存？ 3. 为何线程数量高达401个，远超过预期？ 对于问题1，通过MAT的线程视图，发现只有401个Tomcat工作线程，但这仍远超正常值。对于问题2，这可能是因为Tomcat的实现策略，当收到请求头超过设定值时，尝试一次性分配，导致内存瞬间增大。至于问题3，可能的原因包括线程池配置不当、并发量过高或线程回收机制存在问题。 解决这个问题的关键在于调整配置，将`max-http-header-size`设置为更合理的值，避免一次性分配大量内存。此外，还需要优化线程池配置，确保线程数量适中，防止过多线程导致的资源浪费。在实际操作中，可能还需要结合代码审查、日志分析和性能监控等手段，以找出可能导致高并发和线程过多的具体原因。 通过这次实战，我们可以学到： 1. 使用MAT等工具进行内存分析以定位内存泄漏和异常内存分配。 2. 对于服务器配置，尤其是涉及内存分配的参数，需要谨慎设置，避免过度消耗内存。 3. 监控线程池状态，确保其配置与应用的并发需求相匹配。 4. 当遇到复杂问题时，要从多角度、多层次进行排查，分析日志、理解代码逻辑，并结合系统行为来找出问题根源。