Java笔记3.5--定位排查OOM

什么时候该排查：

1.GC过程中，会Stop the World，不干其他活

2.本该运行好的程序，在某个时刻卡住，业务日志没有异常

3.通过CAT等监控工具，发现某段时间内存用量居高不下

上线后一般接CAT等监控工具，监控内存。如果超出阈值，发出一报警邮件。

4.稳定重现OOM，比如一天一次，或者每天频繁出现

 

通过GC日志确认：

1.能看到GC发生时间和回收的内存量。

2.结合卡的时间点，确认是因为GC造成Stop the World。

3.可定量观察到GC的频繁程度

通过代码，打印 当前日志用量：

runtiome库，输出各种内存用量数值

在可能会大规模使用内存的代码位置，可以查看执行前后的内存用量。

包括但不限于：用到线程池，批量导数据，频繁发起dubbo,kafka等调用，运行时间可能会很长的模块

出现OOM后获取和分析Dump文件：

上线前通过压力测试排查内存问题：

用Jmeter等工具在测试环境上进行压力测试，模拟高并发的请求。压测时，用Zabbix等工具监控内存。内存用量高时，通过GC和业务日志，排查问题。看哪些地方会卡，会报OOM。结合业务日志和GC日志，排查问题。

排查OOM说辞：

1.微信信息处理维护项目上线前，进行压测

2.部署了3台机器，用Jmeter压测，用Zabbix监控内存

4.发现定期出现OOM，用过Dump文件看内存镜像

5.发现创建线程池，使用了无界队列，当信息多时，会出现OOM问题，改为有界队列。

1.爬虫模块，用线程池管理线程，用多个线程爬取信息。

2.上线后经常卡住，用CAT监控，发现内存用量高居不下，而且会出现OOM。

3.经过看Dump日志，发信啊ThreadLocal维护每个线程爬取列表时，ThreadLocal对象没有remove，ArrayList用完没有clear。

4.引出TGhreadLocal，弱引用，内存泄漏，然后remove和clear就OK。

总结：

1.排查OOM问题

2.结合项目给出如何定位OOM

3.多种方法定位排查OOM