大数据将取代石油，成为最重要的资源

故障二：内存泄漏

介绍案例前，先了解一下内存泄漏和内存溢出的区别。

内存溢出：程序没有足够的内存使用时，就会发生内存溢出。内存溢出后程序基本上就无法正常运行了。

内存泄漏：当程序不能及时释放内存，导致占用内存逐渐增加，就是内存泄漏。内存泄漏一般不会导致程序无法运行。不过持续的内存泄漏，累积到内存上限时，就会发生内存溢出。在Java中，如果发生内存泄漏，会导致GC回收不彻底，每次GC后，堆内存使用率逐渐增高。

下图是JVM发生内存泄漏的监控图，我们可以看到每次GC后堆内存使用率都比以前提高了：
 

很多人在面试时，会被问到这样的问题： 遇到过什么系统故障？ 怎么解决的？ 下面是笔者根据自己15年互联网研发经历总结的多个线上故障真实案例。

本文图不多，但内容很干！理解为主，学以致用！

故障一：JVM频繁FULL GC快速排查

在分享此案例前，先聊聊哪些场景会导致频繁Full GC：

1. 内存泄漏（代码有问题，对象引用没及时释放，导致对象不能及时回收）。

2. 死循环。

3. 大对象。

尤其是大对象，80%以上的情况就是他。

那么大对象从哪里来的呢？

1. 数据库（包括MySQL和MongoDB等NoSQL数据库），结果集太大。

2. 第三方接口传输的大对象。

3. 消息队列，消息太大。

根据多年一线互联网经验，绝大部分情况是数据库大结果集导致。

好，现在我们开始介绍这次线上故障：

在没有任何发布的情况下，POP服务（ 接入 第三方商家的服务）突然开始疯狂Full GC，观察堆内存监控没内存泄漏，回滚到前一版本，问题仍然存在，尴尬了！！！

按照常规做法，一般先用jmap导出堆内存快照（jmap -dump:format=b,file=文件名 [pid]），然后用mat等工具分析出什么对象占用了大量空间，再查看相关引用找到问题代码。这种方式定位问题周期会比较长，如果是关键服务，长时间不能定位解决问题，影响太大。

下面来看看我们的做法：

先按照常规做法分析堆内存快照，与此同时另外的同学去查看数据库服务器网络IO监控，如果 数据库服务器 网络IO有明显上升，并且时间点吻合，基本可以确定是数据库大结果集导致了Full GC，赶紧找DBA快速定位大SQL（对DBA来说很简单，分分钟搞定，如果DBA不知道怎么定位，那他要被开除了，哈哈），定位到SQL后再定位代码就非常简单了。

按照这种办法，我们很快定位了问题。原来是一个接口必传的参数没传进来，也没加校验，导致SQL语句where后面少了两个条件，一次查几万条记录出来，真坑啊！ 这种方法是不是要快很多，哈哈，5分钟搞定。

当时的DAO层是基于Mybatis实现的，出问题的SQL语句如下：

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!