直接看日志就能发现内存压力正在升高，关键不是等OOM发生，而是提前捕捉异常信号：重点关注GC日志中Young GC频率加快、Full GC频繁且耗时增长、回收率降低、promotion failed及Allocation Failure等信号，结合错误堆栈（如Java heap space/Metaspace/Direct buffer memory）和系统资源指标（如dmesg OOM Killer记录、top RES超-Xmx）交叉验证，辅以GCViewer/GCEasy、jstat、jmap等工具精准定位泄漏根因。
直接看日志就能发现内存压力正在升高，关键不是等 OOM 发生，而是提前捕捉异常信号。重点盯住 GC 日志、错误堆栈和系统资源指标这三类信息。
启用并解析 GC 日志
GC 日志是判断内存是否“吃紧”的第一手证据。JDK 8 使用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/gc.log；JDK 9+ 推荐 -Xlog:gc*:file=/path/gc.log:time,uptime,level,tags。启用后重点关注：
- Young GC 频率明显加快（比如从每分钟 1 次变成每秒多次），说明新生代对象生成快、存活多
- Full GC 开始频繁出现，且每次耗时增长（FGCT 持续上升），代表老年代空间持续被填满
- GC 后堆内存回收率变低（如每次只回收不到 5%），甚至出现 promotion failed 或 concurrent mode failure
- 日志中反复出现 Allocation Failure，尤其伴随高占用率（如 “heap: 95% used”）
从错误日志定位溢出类型
一旦出现 OutOfMemoryError，日志里那行完整异常就是突破口：
- java.lang.OutOfMemoryError: Java heap space → 立即检查堆转储（需提前配 -XX:+HeapDumpOnOutOfMemoryError）和最近批量操作代码
- java.lang.OutOfMemoryError: Metaspace → 查看是否频繁加载类（如热部署、动态代理、脚本引擎）、类加载器未卸载
- java.lang.OutOfMemoryError: Direct buffer memory → 检查 NIO 相关代码，特别是 ByteBuffer.allocateDirect() 调用及是否调用 cleaner 或 free()
- java.lang.OutOfMemoryError: GC overhead limit exceeded → 不是内存绝对不足，而是 GC 效率崩溃，通常意味着大量短命对象 + 老年代碎片化
- 堆栈末尾若显示 at java.util.Arrays.copyOf 或 new byte[]，大概率是大数组分配失败，可反推业务中是否存在超大数据读取逻辑
用工具辅助分析日志
人工扫日志效率低，建议搭配专业工具提升识别精度：
立即学习“Java免费学习笔记（深入）”；
- GCViewer 或 GCEasy：自动解析 GC 日志，可视化展示各代内存趋势、GC 频次、停顿时间、回收效率，快速识别 “谁在涨”“谁没降”
- jstat -gc <pid>：实时查看内存代使用率、GC 次数与耗时，验证日志结论是否与运行态一致
- jstat -class <pid>：配合 Metaspace 溢出排查，观察 loaded class count 是否持续上涨
- 发现疑似泄漏点后，用 jmap -dump:format=b,file=heap.hprof <pid> 手动触发堆转储，再用 MAT 分析对象分布和引用链
交叉验证系统级日志
单看 JVM 日志容易误判，必须关联操作系统层面输出：
- 在应用日志附近查找 “Cannot allocate memory” 或 “fork: Cannot allocate memory” —— 这是 Linux 系统级内存耗尽，可能因 JVM 堆 + 直接内存 + 线程栈总和超物理内存
- 执行 dmesg -T | grep -i "killed process"，确认是否有 OOM Killer 强杀进程记录
- 结合 top / htop 观察 RES 内存占用是否远超 -Xmx 设置值，提示存在堆外内存泄漏（如 DirectByteBuffer、JNI）
