jvm内存溢出需按证据链精准排查：第一步看错误信息锁定区域（如heap space、metaspace等）；第二步通过-xx:+heapdumponoutofmemoryerror和gc日志留痕；第三步用mat分析dominator tree与leak suspects；第四步结合代码验证静态集合、资源未释放、分页缺失等问题。
JVM 内存溢出不是随机发生的崩溃，而是内存资源耗尽的明确信号。关键在于快速判断类型、锁定源头、验证修复——不靠猜测，靠证据链。
第一步：看错误信息，锁定溢出区域
错误日志是第一手线索，不同提示指向不同内存区域：
- java.lang.OutOfMemoryError: Java heap space → 堆内存不足，重点查对象堆积或泄漏
- java.lang.OutOfMemoryError: Metaspace → 类加载过多，常见于热部署、大量动态代理或反射
- java.lang.StackOverflowError → 单线程栈溢出，多由无限递归或过深调用链引起
- java.lang.OutOfMemoryError: Direct buffer memory → NIO直接内存超限，常因未释放ByteBuffer或池配置不当
第二步：现场留痕，获取分析依据
OOM发生时必须保留堆转储（Heap Dump）和GC日志，否则事后复盘几乎无解：
- 启动参数加：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dumps/ - 同时启用详细GC日志：
-Xlog:gc*:gc.log:time,uptime -XX:+PrintGCDetails - 若无法等OOM再触发，可用
jmap -dump:format=b,file=heap.hprof <pid></pid>主动抓取
第三步：用工具定位“谁吃掉了内存”
堆转储文件不是用来“打开看看”，而是要结构化分析：
- 用MAT（Memory Analyzer Tool）打开.hprof，优先查看Dominator Tree——找出直接支配最多内存的对象
- 运行Leak Suspects Report，自动标记疑似泄漏点（如静态Map持续增长、未关闭的InputStream关联大byte[]）
- 结合Reference Chain追踪对象到GC Root的引用路径，确认为何无法回收
- 对比多个dump时间点，观察某些类实例数是否持续上升（如UserServiceImpl、CachedDataHolder）
第四步：结合代码与运行态交叉验证
工具结果需回归业务逻辑才能落地：
- 检查是否有静态集合类（如static Map
cache）长期持有对象 - 确认资源是否显式释放：数据库连接、文件流、NIO Buffer是否在finally或try-with-resources中关闭
- 排查分页缺失：一次查10万条数据进List，远比查100条×1000次更危险
- 留意第三方组件行为：某些SDK内部缓存未暴露清理接口，或线程池未设上限导致线程+栈内存耗尽
真正有效的排查，是把日志、dump、代码、业务场景串成一条证据链。调大-Xmx能临时缓解，但只有找到那个没被释放的引用、那个没关闭的流、那个没分页的SQL，才算解决问题。
