实战 OOM 排查：利用 jmap 与 MAT 分析 Heap Dump 文件以定位海量 String 对象导致的内存溢出

OOM排查实战：海量String对象引发的内存溢出，如何用jmap+MAT一招定位？

遇到大量String对象引发的OOM，核心不是“删掉字符串”，而是揪出谁在无节制地创建、持有、缓存它们。jmap负责抓现场，MAT负责审线索，两者配合才能快速定位根因。

用jmap抓取有效Heap Dump

生产环境不能等OOM发生才动手，但也不能随便dump——要兼顾准确性与影响可控。 - 优先选live模式：执行jmap -dump:live,format=b,file=heap.hprof ，只保留存活对象，文件更小、分析更快，也更贴近真实泄漏状态。 - 进程卡死时再用-F强制模式：如jmap -F -dump:format=b,file=heap.hprof ，但会跳过GC清理，可能混入本该回收的对象，需在MAT中多一步过滤。 - 提前配置自动dump更稳妥：启动参数加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，OOM一发生，快照就已落盘，避免人工干预延误。 - 注意磁盘和权限：String堆积常导致dump文件达数GB，确保目标路径有足够空间；运行jmap的用户需对Ja va进程有读权限，对输出目录有写权限。

在MAT中聚焦String相关线索

MAT不是看谁占内存多就点谁，而是顺着引用链，找到“不该活却一直活着”的源头。 - 先看Leak Suspects Report：打开dump后自动弹出，重点看“One instance of 'ja va.util.ArrayList' dominates the heap”这类提示——它背后往往就是String容器。 - 直奔Histogram视图，筛选ja va.lang.String：右键→“Group by: Package”，或直接在Class Name栏输入ja va.lang.String；关注“Retained Heap”列，排序后看前几项——哪个包下的String占比异常高？ - 点开高Retained Heap的String实例，查Dominator Tree：看它被谁dominator（支配），通常会指向某个静态Map、ThreadLocal或单例缓存对象。 - 右键→Path to GC Roots→exclude weak/soft references：排除弱引用干扰，只看强引用链；如果路径终点是ja va.lang.ThreadLocal$ThreadLocalMap或static final HashMap，基本锁定泄漏点。

常见String泄漏场景与验证方式

不是所有String多都算问题，得判断是否“业务已结束，引用还挂着”。 - 日志框架中的MDC/NDC：比如SLF4J的MDC.put("traceId", ...)后未clear()，线程复用时traceId累积；检查ThreadLocalMap中key为MDC的entry数量是否随请求增长。 - JSON序列化缓存：FastJSON或Jackson配置了全局缓存策略，反复解析相同结构的字符串，生成大量重复String；在Histogram中观察是否出现大量内容高度相似的String实例。 - 静态集合误用：如public static List cache = new ArrayList<>();，接口每调用一次就add一个UUID字符串，且无清理逻辑；MAT中可看到该List的size持续增大，且每个元素都是新String。 - 数据库字段映射不当：MyBatis将CLOB或长文本字段映射为String，但业务只取前100字符，却把整MB内容全加载进内存；结合SQL日志+MAT中String内容预览可快速识别。

确认并修复后的关键验证动作

改完代码不等于问题消失，得用数据闭环验证。 - 压测对比：用相同流量压测修复前后，观察堆内存使用曲线是否不再持续攀升，Full GC次数是否下降。 - 监控新增指标：在应用中埋点统计关键缓存容器size、MDC entry数量、或自定义JVM指标（如string_cache_size），接入Prometheus+Grafana实时观测。 - 保留一份修复前dump做基线：下次同类问题出现时，可用MAT的Compare Basket功能，快速比对String实例增长差异，节省70%分析时间。