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

微信图片_202207231414372.jpg

### 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 selectByShopIdList(List shopIdList) { Wrapper wrapper = new EntityWrapper<>(); wrapper.in("shop_id", shopIdList); List 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便起飞了...

微信图片_20220723141437.jpg

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