我的第一次给了OOM

OOM终于抓到我了

道听途说

以前总是听别人说OOM什么什么的，刚开始还不知道是什么意思，然后百度了一下，才知道是Out Of Memory的简写，也就是内存溢出的意思。好，面试的时候至少能解释出来了。（之前面试，有人问我：谈一下你对OOP的认识，我直接懵掉，OOP(Object Oriented Programming,面向对象编程) 是什么？？？都不好意思说自己是学java的了）

初次见面

最近在工作中，有家客户的需求做完了，但是一直部署在测试区，之前的负责这家客户的同仁离职了，主管让我去帮他们部署到正式区。其实就是把war包复制然后粘贴到他们正式区的服务器上。我心里也没多想(因为这种部署操作少说也做过100多次了)。中午11点开始部署的，刚部署完，然后准备去吃饭，然后在群里各种疯狂@我，说APP登不进去了，网页端也卡死了(此处省略1w字)，我突然就有点慌，我排查了5分钟左右，没找到问题，无奈之下就帮他们还原之前的版本了。紧接着就去捞日志，结果一搜error关键字，看了下面的一幕

怎么办？

一开始我以为是war包的问题，然后从新打了个包，隔了一天又部署，还是OOM。但是这次在日志里还看到了数据库的错误，然后请公司的大佬改了一下Mysql的配置(修改了缓存，增加了慢查询日志，修改了内存)。

第三次部署，心想：应该就是Mysql的配置问题。结果上线后不到5分钟，又开始卡了。。。这家客户是24 * 7 * 356不间断工作，给他们生产造成了一定损失(主要是3次都不行，而且还没找到问题),客户直接投诉我了。。。我是真滴冤。。。

之后我把他们家的数据库拷到我本地(20个G)，本地测试一点问题没有。然后让多个同事连我的服务器(客户他们家有30多个人同时使用)测试，还是没复现出BUG。此时客户已经开始到处投诉了，一级一级往上投诉。公司的技术人员也没有提供什么实质性的帮助。走投无路的我，都想立地辞职了。。。但作为一个码农，责任精神不能丢，要对自己的代码负责，对BUG负责。于是我就下定决心，坚持信念（柯南看的比较多，所以相信真相只有一个），开始从头分析问题。

分析问题

通过仔细的分析日志，看出客户家是上线后大概使用一段时间才出现了第一次的OOM，之后就有了数据库连接失败的错误，然后就是一个接着一个的OOM。所以我把问题定位到了从上线到第一次OOM这段期间。

静下心来，仔细看报错

功夫不负有心人，在OOM的报错中，我看到了之前同仁写的方法

然后就是去方法里找for循环，找了一圈没看到异常的代码。接着去找和数据库询有关的代码，找了半个多钟头，终于找到一个有可能有问题的sql

一开始看没什么问题呀，就是三张表join了一下。但是看到这<where> 标签后，越来越感觉不对劲。如果下面的<if test> 条件都是空值，那么这个sql就没有了where条件。但是又一想，影响不大吧？算了，还是去数据库看看这几张表的大小吧。不看不知道，一看吓一跳
a表的数据

b表的数据

c表的数据

哎，我本地试了一下没有where条件的查询，好家伙，查了几分钟都没出来结果(电脑不太行)。
LEFT JOIN 相当于笛卡尔乘积，就是1500000 * 1300000 * 8000行的数据量，这谁顶的住啊！！！
然后就试了下有条件的where，果然很快，而且只会查出一条数据。顺着源头去找，最后发现where条件中的一个值在新版的APP端是一个必填项，就是到后端后肯定是有值的，问题就在于部署更新后，客户并没有使用新版APP，导致无条件关联，酿成惨祸。。。昨天刚给客户家更新完，让他们用了新版的APP后，果然一点问题没有，客户对我也客客气气的啦(之前疯狂怼我，当然，我也怼回去了，哈哈)。

总结

这次经历，真的是让我成长了不少，尤其是分析问题上以及与人沟通上(问题期间经常和客户互怼)都给了我很棒的经验。最后总结一下问题产生的原因：

1：由于三张表无条件的关联，最后的结果很大，并且放到了一个List中，导致第一次OOM

2.由于数据量巨大，同时又有很多人在查询，导致查询时间超时，与数据库断开连接，与日志中的Mysql连接失败匹配上了

3.查询操作使Mysql占用内存飙升，当时看任务管理器，Mysql占用了98%(24G的内存),导致服务器与Mysql连接失败，产生登录不进去，服务器没反应的状况。

回过头来这么一看，目前来看，OOM要么就是代码里有死循环，要么就是从数据库中查到了很多的数据放到一个集合中了。
解决完这个问题后，心里有种莫名的成就感，还隐约有种期待，期待下一次与OOM的相遇。
我的第一次就是这么给了OOM!