记录1次MybatisWrapper导致的生产事故

　　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 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便起飞了...
　　在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给你留坑！！！