什么时候该排查：
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
