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终于降下来了…

记录1次Mybatis-Wrapper导致的生产事故

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个查询罢了啊，有啥问题吗？

记录1次Mybatis-Wrapper导致的生产事故

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

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

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

但是今日突然有shopIdList = [] 传进来了，所以CPU便起飞了…

记录1次Mybatis-Wrapper导致的生产事故

在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给你留坑！！！

记录1次Mybatis-Wrapper导致的生产事故