JVM系列之OOM观测准备

       OOM, 全称 “Out Of Memory”,即内存用完的意思。JVM 因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时(可分配内存大于需要分配的内存), 就会抛出 java.lang.OutOfMemoryError。在实际的生产应用中,一旦出现OOM,很可能应用面临崩溃,服务器CPU资源被消耗尽,这是非常可怕的事。

  

      jvisualvm(Java VisualVM),能够监控线程,内存情况,查看方法的CPU时间和内存中的对象,已被GC的对象,反向查看分配的堆栈,是JDK提供非常好用的可视化图形观察内存情况的工具。

想通过jvisualvm远程观测虚拟机的内存情况,可以通过在JVM参数配置加上以下配置(生产不建议配)

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=xxxport -Dcom.sun.management.jmxremote.ssl=false    - Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=xxxip

参数解释如下:

-Dcom.sun.management.jmxremote   添加一个jmx远程连接属性
-Dcom.sun.management.jmxremote.port=xxxport  指定连接的应用端口号
-Dcom.sun.management.jmxremote.authenticate=false 是否启用验证
-Dcom.sun.management.jmxremote.ssl=false 是否启用ssl
-Djava.net.preferIPv4Stack=true 是否优先使用ipv4
-Djava.rmi.server.hostname=xxxip 指定远程主机的ip地址

在jdk的bin目录下双击jvisualvm,远程主机添加远程主机,然后添加JMX连接,使用安全凭证登录,即可远程观察JVM的运行情况,在压测或者复现生产问题故障十分有效。

连接上去,可以看到一个健康的Java应用的内存回收折线图。

我们还可以通过jstat工具来查看应用的回收情况。jstat -gcutil xxx 3s  每三秒输出xxx(进程号)内存回收情况。这个可以在生产在线环境查看,对判断应用健康很有帮助。

S0:幸存1区当前使用比例

S1:幸存2区当前使用比例

E:伊甸园区使用比例

O:老年代使用比例

M:元数据区使用比例

CCS:压缩使用比例

YGC:年轻代垃圾回收次数

FGC:老年代垃圾回收次数

FGCT:老年代垃圾回收消耗时间

GCT:垃圾回收消耗总时间

从上图可以看出,老年代频繁回收,3秒已经进行了好几次fullGC,且老年代做垃圾回收并没有释放多少内存,即内存溢出了,CPU基本都在忙着做垃圾回收,说明已经OOM了。下图通过top命令可以看到第一个进程CPU飙升,它正是此我们监测的Java应用正上演着OOM,应用已不能正常处理业务。

<think>嗯,用户问的是OOM溢出怎么排查和解决。首先,我得回忆一下OOM是什么。OOM就是Out Of Memory,内存溢出,通常发生在Java应用里,但其他语言也可能有。用户可能遇到了程序崩溃,或者性能问题,需要知道怎么处理。 首先,排查问题。需要确定错误类型,比如Java的OutOfMemoryError有不同的子类,比如堆溢出、元空间溢出等。这时候需要看日志,找出具体的错误信息。如果是堆溢出,可能是对象太多无法回收;元空间的话可能是类加载器的问题。 然后,用户可能需要分析堆转储。生成堆转储文件可以用jmap或者JVM参数自动生成。用MAT或者VisualVM这些工具来分析,找出内存泄漏的对象。比如,查看支配树,找到占用内存最大的对象,看看是否有不应该存在的引用。 接着是内存监控。用jstat看内存使用情况,各个代的变化,GC频率和效果。如果老年代一直增长,可能是有内存泄漏。另外,用top或者htop看系统内存,确认是不是物理内存不足导致的。 线程和堆栈分析也可能有帮助,比如jstack查看线程是否有死锁或者大量等待,虽然不一定直接关联OOM,但有时候资源竞争会导致问题。 代码审查方面,检查是否有大对象频繁创建,或者缓存没有限制,静态集合未清理等。比如,静态Map不断添加数据,没有移除机制,就会导致内存泄漏。 解决问题的话,调整JVM参数是常见方法,比如增大堆大小,设置元空间大小,调整GC算法。比如-XX:+UseG1GC可能更适合大堆。另外,优化代码,避免内存泄漏,及时释放资源,使用弱引用等。 引入内存分析工具,比如在测试环境用Valgrind或JProfiler提前发现问题。如果是系统内存不足,可能需要加内存或者优化其他进程的使用。 用户可能需要具体的例子,比如如何生成堆转储,或者MAT的使用步骤。但用户的问题比较概括,可能需要分步骤说明,确保他们能一步步操作。 还要考虑用户的技术水平,可能不熟悉命令行工具,所以需要给出常用命令,比如jmap -dump,或者JVM参数-XX:+HeapDumpOnOutOfMemoryError。同时,提醒他们测试环境和生产环境的区别,避免在线服务受影响。 总结下来,排查OOM需要结合日志、堆转储分析、监控工具和代码审查,解决则需要调整参数、优化代码和资源管理。需要结构清晰,分步骤说明,确保用户能理解并操作。</think>### OOM(Out Of Memory)溢出排查与解决指南 #### 一、问题定位 1. **明确错误类型** OOM 错误通常伴随具体类型(如 `Java heap space`、`Metaspace``、`GC overhead limit exceeded` 等),需通过日志或报错信息确定根源。 - **堆内存溢出**:对象数量超出堆容量,常见于缓存未限制、大对象未释放。 - **元空间溢出**:加载的类信息超出 Metaspace 限制,常见于动态生成类(如反射、CGLIB)。 - **直接内存溢出**:NIO 使用的堆外内存不足,常见于未正确释放 `ByteBuffer`。 2. **生成内存快照(Heap Dump)** - **手动触发**:通过 `jmap` 工具导出堆转储文件: ```bash jmap -dump:format=b,file=heapdump.hprof <pid> ``` - **自动触发**:在 JVM 启动参数中添加: ```bash -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump ``` 3. **分析内存占用** 使用工具(如 **Eclipse MAT**、**VisualVM**、**JProfiler**)分析堆转储文件: - **Dominator Tree**:定位占用内存最大的对象。 - **Leak Suspects Report**:自动检测潜在内存泄漏。 - **Histogram**:按类统计对象数量,排查异常增长类。 4. **监控内存动态变化** - **JVM 内存监控**: ```bash jstat -gcutil <pid> 1000 # 每秒打印 GC 统计信息 ``` - **系统级监控**: 使用 `top`、`htop` 或 `Prometheus + Grafana` 观察物理内存和交换分区使用情况。 --- #### 二、常见原因 1. **内存泄漏** - **静态集合未清理**:静态 Map/List 长期持有对象引用。 - **未关闭资源**:数据库连接、文件流、线程池未释放。 - **监听器未注销**:事件监听器未移除导致对象无法回收。 2. **配置不合理** - **堆内存设置过小**:未根据业务需求调整 `-Xmx` 和 `-Xms`。 - **Metaspace 不足**:动态加载类过多,未调整 `-XX:MaxMetaspaceSize`。 - **GC 策略不当**:频繁 Full GC 但回收效率低。 3. **代码设计问题** - **大对象频繁创建**:如一次性加载超大文件到内存。 - **缓存未限制**:本地缓存未设置 LRU 淘汰策略或 TTL。 --- #### 三、解决方案 1. **调整 JVM 参数** - **堆内存扩容**: ```bash -Xmx4g -Xms4g # 根据实际需求设置 ``` - **优化 Metaspace**: ```bash -XX:MaxMetaspaceSize=512m ``` - **优化 GC 策略**: ```bash -XX:+UseG1GC # 对大堆场景更友好 ``` 2. **修复内存泄漏** - **清理无用引用**:确保集合对象在不再使用时置为 `null`。 - **使用弱引用**:对缓存场景改用 `WeakHashMap` 或 `SoftReference`。 - **关闭资源**:在 `finally` 块中释放连接、流等资源。 3. **优化代码逻辑** - **分页处理数据**:避免一次性加载全量数据到内存。 - **限制缓存大小**:使用 `Guava Cache` 或 `Caffeine` 设置上限和淘汰策略。 - **减少对象创建**:复用对象(如通过对象池)或使用基本类型替代包装类。 4. **引入监控与告警** - **APM 工具**:通过 **Arthas**、**SkyWalking** 实时监控内存使用。 - **日志分析**:通过 ELK 收集 OOM 相关日志并设置阈值告警。 --- #### 四、验证与预防 1. **压力测试** 使用 **JMeter** 或 **Gatling** 模拟高并发场景,观察内存增长是否正常。 2. **代码审查** 定期检查静态集合、资源释放逻辑和缓存设计。 3. **容器化部署** 在 Kubernetes 中设置内存 Limit,防止单一 Pod 耗尽节点资源。 --- **总结**:OOM 问题需结合日志分析、内存快照和监控工具定位根本原因,通过参数调优、代码优化和资源管理综合解决。关键是通过可观测性手段提前预防,而非被动应对。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值