1. JVM内存问题排查实战指南上周排查一个线上OOM问题时发现不少同事对JVM内存问题的排查思路不够系统。作为经历过无数次内存血案的老兵今天就把压箱底的排查方法论整理出来。不同于教科书式的理论讲解这里全是能直接用在生产环境的实战技巧。JVM内存问题通常表现为频繁Full GC、服务卡顿、OOM崩溃等。这些问题轻则影响性能重则直接导致服务不可用。掌握系统化的排查方法能帮你在关键时刻快速定位问题源头。下面就从工具使用、问题定位到优化方案带你走完整个排查闭环。2. 排查工具的选择与使用技巧2.1 基础工具三件套先介绍三个最常用的命令行工具所有Linux系统都自带# 查看进程基础信息 top -Hp [pid] # 查看内存概况 jstat -gcutil [pid] 1000 10 # 生成堆转储文件 jmap -dump:live,formatb,fileheap.hprof [pid]重要提示生产环境执行jmap前务必先和运维确认因为会造成服务短暂停顿2.2 可视化工具推荐VisualVMJDK自带适合本地开发环境MAT(Memory Analyzer Tool)分析堆转储文件的瑞士军刀Arthas阿里开源的线上诊断神器以MAT为例分析堆转储时的关键步骤加载hprof文件后先看Leak Suspects报告检查Dominator Tree中的大对象用Path to GC Roots追踪引用链2.3 监控指标看哪些建议重点关注这些JMX指标堆内存各区域使用率Young/Old区GC次数和耗时特别是Full GC线程数变化趋势类加载数量3. 典型内存问题排查实战3.1 内存泄漏(Memory Leak)特征堆内存使用量持续增长Full GC后也无法回落排查步骤间隔10分钟做两次堆转储用MAT对比两个dump文件的对象增长情况重点检查集合类HashMap、ArrayList等分析增长对象的引用链典型案例静态集合缓存未清理线程池未正确关闭第三方库的资源未释放3.2 内存溢出(OOM)常见错误类型Java heap space堆内存不足Metaspace元空间不足Unable to create new native thread线程数超限快速定位法在JVM参数中添加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump.hprof复现问题后分析自动生成的dump文件检查OOM时的线程栈jstack3.3 GC问题调优症状识别Young GC频繁 → Eden区太小Full GC频繁 → Old区占用高GC停顿时间长 → 堆内存过大调优参数示例# 针对CMS收集器的典型配置 -XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction75 -XX:UseCMSInitiatingOccupancyOnly4. 高级排查技巧4.1 堆外内存排查当top显示的内存使用远超Xmx设置时可能是堆外内存问题使用NMT(Native Memory Tracking)-XX:NativeMemoryTrackingdetail jcmd [pid] VM.native_memory detail检查DirectByteBuffer使用情况排查JNI调用和第三方native库4.2 容器环境特殊问题在Docker/K8s环境中特别注意确保设置了正确的内存限制JVM能感知容器内存限制-XX:UseContainerSupport -XX:MaxRAMPercentage75.0小心Page Cache占用过高5. 预防与最佳实践5.1 编码规范避免静态集合滥用及时关闭IO资源合理设置缓存大小和过期时间5.2 监控体系建议配置以下告警堆内存使用率 80%Full GC次数突增GC时间超过阈值5.3 压测验证上线前务必进行内存泄漏测试长时间压测极限负载测试OOM边界测试GC压力测试6. 疑难案例解析最近遇到一个典型问题服务每隔几天就会OOM重启。通过以下步骤最终定位对比多个时间点的堆转储发现ThreadLocal对象持续增长检查代码发现使用了未清理的ThreadLocal线程池复用导致ThreadLocal积累解决方案// 使用后必须remove threadLocal.set(value); try { // 业务代码 } finally { threadLocal.remove(); }7. 性能优化checklist每次发布前检查[ ] 是否有大对象缓存[ ] 集合大小是否有限制[ ] 所有资源都有释放逻辑吗[ ] 线程池配置是否合理[ ] 日志输出会内存爆炸吗8. 工具链推荐我的常用工具组合生产环境Arthas Prometheus Grafana开发环境VisualVM JProfiler堆分析MAT JOverflow日志分析ELK GC日志分析器对于线上问题我通常会先用Arthas快速诊断必要时再下载堆转储用MAT深入分析。这个组合能解决90%的内存问题。9. 常见误区与教训误区一加大Xmx就能解决问题真相可能只是延迟OOM发生时间误区二GC日志没报错就没问题真相需要结合监控看GC频率和耗时血泪教训曾经因为未限制Excel导出数据量导致OOM因未关闭WebClient连接导致连接泄漏缓存没有过期策略最终撑爆内存10. 进阶学习建议想深入掌握内存管理的推荐学习《深入理解Java虚拟机》Java各GC算法实现原理Linux内存管理机制常见中间件的内存模型最后分享一个救命技巧当线上突然OOM时立即用jcmd生成堆转储然后尽快重启服务恢复业务。事后分析dump文件比盲目猜测高效得多。