1.灾难回顾

1）某日早上，生产环境告警群出现了慢接口告警，随之而来的是CPU告警。

2）因为最近没有上新功能，所以初步猜测是否中间件或数据库出了问题？经排查，各中间件一切正常，数据库慢sql也不算很慢。

3）在主机上使用top命令查看CPU占用情况，发现有异常：主机CPU一直保持在1000%（主机16核），一直持续。

4）有了上次的经验，第一时间看GC情况：jstat -gcutil pid 1000。果然，发现FGC每几秒就增加1次，说明JVM在疯狂进行Full GC，至于为什么会频繁Full GC，一脸茫然。

第一反应是重启部分机器，留1台机器进行dump内存快照。

5）10分钟后，经分析快照，发现有个类ShopAddress占内存特别大，包含对象数150多万。

6）使用jstack命令（jstack -l pid）查看JVM线程，搜索关键词ShopAddress，发现的确是有关于ShopAddress的堆栈信息。

7）基于堆栈信息找到对应的代码，修改代码并发布到生产环境，CPU终于降下来了...

2.场景简化回顾

假如说有这么一张表

CREATE TABLE `t_shop_address` (
 `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
 `shop_id` int(11) NOT NULL COMMENT 't_shop.id',
 ...
) COMMENT='门店地址';

需求是：需要根据多个shop_id同时查询数据，于是某老6写了以下的代码

public List<ShopAddress> selectByShopIdList(List<Integer> shopIdList) {
    Wrapper<ShopAddress> wrapper = new EntityWrapper<>();
    wrapper.in("shop_id", shopIdList);
    List<ShopAddress> shopAddressList = shopAddressMapper.selectList(wrapper);
    return shopAddressList;
}

就1个查询而已啊，有啥问题吗？

Wrapper是mybatis ORM框架用来组装sql类。翻译过来的sql应该是：

select * from t_shop_address where shop_id in(?,?,?,...);

即使t_shop_address表中存储了大量数据，只要shopIdList的数据量比较少，该查询都不会有问题。

但是今天突然有shopIdList = [] 传进来了，于是CPU便起飞了...

在mybatis的Wrapper API中，如果value为null或者空列表的情况下，组装的sql会忽略该条件

从而导致上面的查询sql为：

select * from t_shop_address;

结果是全表查询，150多万的数据量，这就是JVM会疯狂进行Full GC的原因。

3.预防措施

1）使用Wrapper查询之前增加每一个参数的非空校验，确保都是有值的。

2）避免使用Wrapper来组装条件查询数据库，尽量自己写sql，即时是shop_id in()，最多也只是该业务报错，而不会导致整个系统垮掉。

但还是建议不要出现shop_id in()的情况，这个会报sql语法错误。可以增加1<>1条件让sql正确执行并返回0条数据。

3）使用mybatis拦截器来统一限制查询条数，为每个查询增加limit限制，比如1次查询最多返回1000条结果，当触发limit限制的情况下可以告警。如果超过1000条，需要进行分页查询。

怎么样？还不赶快去看看你的项目，看看有没有老6给你留坑！！！