一起SQL引发OOM的解决思路与过程(转载)

在TOMCAT WEB程序的运行过程中，突然触发了内存溢出错误，检查Tomcat的localhost日志，找到如下信息：

java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:2245)
        at java.util.Arrays.copyOf(Arrays.java:2219)
        at java.util.ArrayList.grow(ArrayList.java:242)
        at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)
        at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)
        at java.util.ArrayList.add(ArrayList.java:440)
        at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:3442)
        ……
        at com.yiifaa.indicator.impl.HoleIndicatorServiceImpl.expireHoles(HoleIndicatorServiceImpl.java:191)
        at com.yiifaa.indicator.controller.HoleIndicatorController.expireHoles(HoleIndicatorController.java:69)

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

按照提示，找到代码进行检阅：

Map<String, Object> params = Maps.newHashMap();
String sql = sqlCache.get("expireHoles");
//  这里就是191行
List<Map<String, Object>> results = this.jdbcTemplate.queryForList(sql, params);

• 1
• 2
• 3
• 4

看了好几遍，没有发现明显的异常，既没有全局变量，也没有属性变量，没理由出现内存溢出，更重要的是，按照以往的经验，SQL应该没有这么大的爆炸力，而且难以确定的是，到底是该方法引发了OOM异常，还是碰巧就遇到了内存的瓶颈，从而导致内存异常，所以需要进一步判断。

刷新页面，调用应用程序接口，同时使用jstat监测JVM内存使用，如下：

# 首先获取程序ID
jps -l
# 然后根据程序ID获取其JVM内存使用信息
# 10代表时间间隔，毫秒
jstat -gcutil 47279 10

• 1
• 2
• 3
• 4
• 5

执行jstat命令后，发现如表1的现象：

S0	S1	E(年轻代占比)	O(老年代占比)	P(永久代占比)
不变	持续增长	持续增长	持续增长	不变

增长的顺序依次是E(年轻代占比)增长到100%，然后S1增长到100%，然后O(老年代占比)增长到100%，最后触发full gc（全局垃圾回收），并且在内存变化的这段时间，并没有进行任何操作，连接数量也在比较小的范围。

#   统计HTTP连接的活动线程
jstack 47279|grep http-bio-8080-exec|grep runnable|wc -l
#   统计HTTP连接数量
 netstat -nat|grep -i '8080'|wc -l

• 1
• 2
• 3
• 4

上述两个命令相互论证，证明HTTP连接是正常的，继续用jstack进行诊断，发现很多HTTP线程处于“WAITED”状态，这说明都是处于连接池中，等待被激活，依旧正常。

继续推测，内存的增长必然伴随对象数量的增加，于是采用jmap进行诊断，如下：

jmap -histo 47279|less 

• 1

持续多次运行此命令，发现有个对象数量以及增长速度都不正常，如下：

1716115  41187603  com.mysql.jdbc.ByteArrayRow

• 1

难道真是数据库连接的问题？突然想到，消耗内存较多的代码一定是运行中的线程，于是用jstack获取到的信息依次诊断线程，发现真有个数据库线程不正常，如下：

http-bio-8080-exec-89" daemon prio=10 tid=0x00007f039c09f800 nid=0xbcd1 runnable [0x00007f05350cc000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:152)
        at java.net.SocketInputStream.read(SocketInputStream.java:122)
        at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
        at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
        at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
       ……
        at com.yiifaa.sec.indicator.impl.HoleIndicatorServiceImpl.expireHoles(HoleIndicatorServiceImpl.java:191)

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

发现程序依旧卡在HoleIndicatorServiceImpl类的191行，最后诊断SQL语句，发现少了一个括号，导致or语句连接数量增长极快，从而是数据量达到了10的22次方，最后引发了如此大的执行灾难。

继续细化分析下去，因为返回结果是个List容器，所以随着游标的滑动，导致数据集不断增长，从而使得“com.mysql.jdbc.ByteArrayRow”对象数量暴增，最后导致内存溢出，结合内存的增长趋势，可以明显看出，当方法内部的对象增大到一定程度时，将会直接进入幸存代（S1），甚至是老年代。

总结

从内存的增加现象看： 
1. 只要对象足够大，完全有可能直接进入老年代，即使实在局部方法内； 
2. 局部方法也可能会导致内存溢出；

从诊断过程看，相关工具的作用如下： 
1. 用jps获取jvm进程ID； 
2. 用jstat确认GC内存消耗速度； 
3. 用jmap确认对象的增长速度与耗费空间； 
4. 用jstack确认错误代码的位置。

从SQL的教训看： 
1. 在多表连接时，请仔细检查连接语句； 
2. 万无一失的做法，请限定抓取数据的数量，例如100条，如“limit 0, 100”。

原文地址i：https://blog.csdn.net/yiifaa/article/details/78648358