定位OOM的工具

OOM的情况很多,有jdk的bug,有不正确的编程习惯等等。


这里记录一下一下工具和步骤,方便自己以后使用。

1.多次收集Thread Dump信息
kill -3 PID
通过对比分析heap 对象信息和Thread信息来定位


2
.通过 -Xloggc:D:/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:/test.hprof
来收集heap dump 信息
.通过MAT来查看堆里比较大块的对象是些啥。如果有些很明显的业务对象占了很大空间,并且创建它们的点很少且都已知,就可以很快缩小追查范围。


3.通过google-perftools工具分析
http://code.google.com/p/google-perftools/


4.通过Btrace来定位
http://kenai.com/projects/btrace


参考:
http://blog.youkuaiyun.com/arkblue/article/details/6124237
http://blog.bluedavy.com/?p=205
<think>好的,我现在需要帮助用户了解如何使用阿里Arthas定位OOM问题。首先,我得回忆一下OOM的常见原因,比如内存泄漏、大对象、过高的并发请求等。然后,Arthas作为诊断工具,具体有哪些命令可以用呢? 首先,用户可能需要知道如何启动Arthas。通常是通过attach到目标Java进程,所以需要知道进程ID。可能得提到使用`java -jar arthas-boot.jar`然后选择进程。 接下来,关键的命令有哪些呢?我记得`dashboard`可以看整体情况,包括内存使用情况,这样能快速发现哪个区域内存异常,比如堆内存的老年代持续增长。然后是`heapdump`命令,可以生成堆转储文件,用MAT或者JVisualVM分析。但用户可能更想在线诊断,这时候`jvm`命令查看内存各区域的情况,比如老年代的使用量和GC情况。 另外,内存对象统计很重要,`memory`命令可以统计堆里的对象数量,比如是否有某个类的实例异常多。这可能指向内存泄漏的类。`ognl`表达式可能用来查看静态变量或者某些大对象,但用户可能需要例子来说明如何用。 还有,线程问题也可能导致OOM,比如大量线程创建不释放,这时候`thread`命令可以查看线程状态和堆栈,不过这可能和OOM关系不大,除非是栈内存溢出,但用户的问题更可能指堆OOM。 需要分步骤说明,比如先监控整体内存,再检查对象统计,生成堆转储,分析大对象或泄漏对象。同时,注意不同内存区域的情况,比如Metaspace、堆内各个区。可能还要提到JVM参数,比如是否开启了HeapDumpOnOutOfMemoryError,但Arthas可以在不重启的情况下生成heapdump,这对线上问题很有用。 还需要注意权限问题,生成heapdump可能需要足够的磁盘空间,以及Arthas的权限。另外,实时监控的时候,比如用`vmtool`获取某个对象实例的数量变化,或者调用方法,但可能比较复杂。 可能遗漏的点:如何安装Arthas,是否需要下载,或者直接attach。另外,可能提到一些案例,比如查出是某个缓存不断增长,或者数据库连接未关闭,导致对象无法回收。还有,如何结合GC日志分析,但用户的问题主要用Arthas,所以可能不需要展开GC日志部分。 最后,确保步骤清晰,从启动Arthas,到基础命令,到详细分析,最后生成dump文件,用工具分析。需要避免技术术语太多,用中文解释清楚每个步骤的目的,比如为什么先看dashboard,再看jvm内存统计,然后对象数量,逐步缩小问题范围。</think>以下是使用阿里Arthas定位OOM问题的步骤详解: --- ### **一、OOM问题定位思路** 1. 确认内存溢出区域(堆、元空间、直接内存等) 2. 查找内存中异常对象(数量过多或体积过大) 3. 分析对象引用链,定位泄漏代码 --- ### **二、Arthas核心操作步骤** #### **1. 启动Arthas** ```bash # 下载并启动(需在Java环境) java -jar arthas-boot.jar # 选择目标Java进程PID ``` --- #### **2. 基础诊断命令** - **查看实时内存/线程状态** ```bash dashboard ``` - 重点关注`heap`内存区域使用率 - 观察`Metaspace`或`Direct Memory`(非堆内存溢出时) - **查看JVM内存状态** ```bash jvm ``` - 检查各内存区域最大值(Max)、已提交量(Committed) --- #### **3. 堆内存分析** - **统计对象实例数量** ```bash memory --classLoaderClass org.springframework.boot.loader.LaunchedURLClassLoader ``` - 按实例数量排序,找到异常类(如`char[]`、`String`或业务类) - **查看对象引用链** ```bash vmtool -x 3 --action getInstances --className java.lang.String --express 'instances.length' ``` - `-x 3`指定展示引用链深度 - 替换类名为实际可疑类 - **生成堆转储文件** ```bash heapdump --live /tmp/heapdump.hprof ``` - 使用MAT/JVisualVM分析文件,定位占用最大的对象 --- #### **4. 非堆内存排查** - **直接内存泄漏检查** ```bash ognl '@java.nio.Buffer@directMemoryTotal()' ``` - 对比正常状态与异常状态的直接内存占用 - **元空间溢出检查** ```bash jvm -m ``` - 观察`Metaspace`的`Used`是否接近`Max` --- #### **5. 高级排查技巧** - **监控方法调用** ```bash monitor -c 5 com.example.service.*Service *Method ``` - 统计高频调用的方法,定位异常业务逻辑 - **追踪类加载** ```bash classloader -t ``` - 检查是否有重复加载的类(如热部署导致) --- ### **三、典型场景案例** #### **场景1:线程池未释放** - 通过`thread`命令查看活跃线程 - 结合`jstack`分析线程堆栈 #### **场景2:缓存未清理** - 用`memory`命令发现缓存类实例数量持续增长 - 通过`heapdump`分析缓存键引用来源 --- ### **四、注意事项** 1. 生成Heapdump时确保磁盘空间充足 2. 生产环境谨慎执行耗时操作(如全量Heapdump) 3. 结合GC日志分析(`jstat -gcutil PID 1000`) 通过以上步骤,可系统化定位内存泄漏点或大对象来源。实际应用中需结合代码逻辑综合分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值