优化第一步：加大堆内存所以这OOM，不能一口说是代码问题，从JVM运行情况及内存大小来看，其实是内存分配不足问题 。
第一步，直接在4核8G的机器上，加大堆内存，直接给堆5G 。
接着运行系统，jstat发现，每次YGC过后存活对象都落入Survivor区域了，不会随便进入老年代，而且因为堆内存很大，基本上运行一段时间不会发生OOM问题了 。
优化第二步：改写代码让他不要占用过多内存 。代码之所以递归，是因为在一条日志中，可能出现很多用户的信息，一条日志也许会合并包含了十几个到几十个用户的信息 。
这时代码中就是会递归处理日志，每次递归都会产生大量char[]数组，是切割了日志用来处理的 。
这代码写的完全没必要，因为对每一条日志，若发现包含多个用户的信息，就对这一条日志切割出来进行处理，没必要递归调用，每次调用都切割一次日志，生成大量char[]数组 。
该步代码优化后，线上系统的内存使用情况降低10倍以上 。
总结先通过OOM的排查方法去分析，发现主要是内存太小导致的问题然后用gc日志和jstat分析，明显发现是内存不够用了，最后加大系统内存，并优化代码即可 。
【亿级流量的数据清洗系统OOM排查实战】
推荐阅读
- 值得收藏！9款小众但功能强大的智能神器
- 如何修复或去除图片上的多余水印或痕迹photoshop
- 7个最好的Go语言Web框架
- HTML5 标签里的 crossorigin 属性到底有什么用？
- 如何将不同linux服务器的目录内容进行双向同步
- 路由交换学习：H3C模拟器HCL的使用
- 图解月薪3w运营应该掌握的知识
- AI 技术驱动的创意图像编辑器
- 高性能的Web服务器Gunicorn 20.1配置Superset 1.4
- 头条99天收入1万，新手必看的8个建议，可以让你快速实现经济独立