线上Java应用内存占用过高问题排查
一、分析JVM当前内存占用情况
如果是裸机部署，直接在机器终端输入java命令排查；如果是在容器内运行，使用docker exec -it bash 进入容器，再输入java命令
1. 命令行工具
以下工具通过终端直接获取内存信息：
| 工具 | 命令示例 | 用途说明 |
|---|---|---|
| jcmd | jcmd VM.native_memory |
显示JVM原生内存分配详情（需-XX:NativeMemoryTracking=detail） |
| jstat | jstat -gcutil 1000 5 |
每1秒打印一次GC内存区域利用率，共5次 |
| jmap | jmap -heap |
输出堆内存配置及使用情况（可能触发STW） |
| ps/top | top -p |
查看进程物理内存和CPU占用 |
备注：STW解释：stop the world（STW）机制是指在JVM运行过程中，所有的应用线程都会被暂停，JVM会执行一些特定的任务，如垃圾回收、线程栈的调整等。
在JVM执行STW期间，所有的应用线程都会被暂停， 这样可以避开在执行关键任务时，应用线程对数据进行修改，从而确保数据的一致性。
无论选择何种垃圾收集算法，都无法完全避开STW的发生，只能尽量减少STW的时间。
此外，STW机制还可以为JVM执行一些重要的任务，如垃圾回收、内存管理等，以提高JVM的性能和效率。
示例输出 (jstat -gcutil)：
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 50.00 85.20 75.30 95.80 90.12 15 0.250 3 0.750 1.000
- 各列含义：S0/S1（Survivor区）、E（Eden区）、O（老年代）、M（Metaspace）、CCS（压缩类空间）、GC次数与时间。
2. 图形化工具
- VisualVM/ JConsole：实时监控堆、线程情况。
- **Java Mission Control (JMC)**：提供详细内存分析、线程热点等（需开启JMX）。
监控指标示例：
| 内存区域 | 使用量 (MB) | 最大值 (MB) | 使用率 (%) |
|---|---|---|---|
| 堆内存 (Heap) | 512 / 1024 | 2048 | 50% |
| Metaspace | 128 / 256 | 512 | 50% |
| Code Cache | 45 / 48 | 240 | 18% |
3. 代码内部分析
通过Java API获取内存数据：
public class MemoryMonitor {
public static void main(String[] args) {
Runtime runtime = Runtime.getRuntime();
long maxMemory = runtime.maxMemory(); // JVM最大可用内存
long totalMemory = runtime.totalMemory(); // 当前分配的堆内存
long freeMemory = runtime.freeMemory(); // 堆内存中空闲部分
long usedMemory = totalMemory - freeMemory; // 实际使用内存
System.out.printf("Max: %.2f MB\n", maxMemory / 1024.0 / 1024);
System.out.printf("Used: %.2f MB\n", usedMemory / 1024.0 / 1024);
}
}
输出示例：
Max: 1820.50 MB
Used: 432.75 MB
二、OOM问题分析流程
1. 配置JVM参数捕获关键信息
启动时添加以下参数：
-XX:+HeapDumpOnOutOfMemoryError # OOM时自动生成堆转储
-XX:HeapDumpPath=/path/to/dumps # 指定转储文件路径
-XX:+PrintGCDetails # 打印GC日志
-XX:+PrintGCDateStamps # GC时间戳
-Xloggc:/path/to/gc.log # GC日志输出路径
2. 分析堆转储文件
使用工具（如Eclipse MAT、VisualVM、jhat）分析.hprof文件：
可以使用的命令：
获取PID
jps
jmap -dump:format=b,file=heap_dump.hprof <PID>
MAT关键操作：
- Histogram：按对象数量/内存占用排序。
- Dominator Tree：识别占用内存最大的对象及其引用链。
- Leak Suspects Report：自动生成泄漏嫌疑报告。
示例MAT报告片段：
Problem Suspect 1: 89.5%内存由ThreadLocal实例持有
- 通过com.example.MyClass.context 引用链保持
3. 检查线程堆栈
结合jstack或日志中的异常堆栈：
jstack <PID> > thread_dump.txt
关键排查点：
- 大量线程阻塞在同一个方法（如资源竞争）。
- 线程持有未释放的锁或数据库连接。eg.分布式锁未及时释放
4. 代码审查与优化
| 常见内存泄漏场景 | 解决方案 |
|---|---|
| 静态集合缓存未清理 | 使用WeakHashMap或定期清理 |
| 未关闭的IO/数据库连接* | 添加finally块或try-with-resources |
| 第三方库内存泄漏（如Netty） | 升级版本或参考社区修复方案 |
5. 内存优化策略
- 调整JVM参数：增加堆大小（
-Xmx）、调整年轻代比例（-XX:NewRatio）。 - 优化代码逻辑：减少大对象分配、减少长时间持有引用。
- 分代调优：若频繁Full GC，可增大老年代或优化对象晋升策略。
三、辅助分析表格
JVM内存区域说明表：
| 内存区域 | 存储内容 | 常见OOM原因 |
|---|---|---|
| 年轻代 (Young) | 新创建的对象 | 短生命周期对象过多，Minor GC频繁 |
| 老年代 (Old) | 长期存活的对象 | 内存泄漏或堆大小不足 |
| Metaspace | 类元数据 | 动态生成类过多（如反射、CGLIB） |
| 直接内存 (Direct) | NIO Buffer分配的内存 | 未显式释放或-XX:MaxDirectMemorySize过小 |
四、总结步骤
- 预防阶段：启用监控（如Prometheus + Grafana）定期检查内存趋势。
- OOM发生时：自动捕获堆转储和GC日志。
- 分析阶段：使用MAT定位大对象，结合线程堆栈和代码审查确定根本原因。
- 修复验证：优化代码后通过压力测试确认内存回归正常。
通过以上方法，及时定位产生内存泄露的代码，及时修改，保证线上环境稳定！
