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

　　1。灾难回顾
　　1）某日早上，生产环境告警群出现了慢接口告警，随之而来的是CPU告警。
　　2）因为最近没有上新功能，所以初步猜测是否中间件或数据库出了问题？经排查，各中间件一切正常，数据库慢sql也不算很慢。
　　3）在主机上使用top命令查看CPU占用情况，发现有异常：主机CPU一直保持在1000（主机16核），一直持续。
　　4）有了上次的经验，第一时间看GC情况：jstatgcutilpid1000。果然，发现FGC每几秒就增加1次，说明JVM在疯狂进行FullGC，至于为什么会频繁FullGC，一脸茫然。
　　第一反应是重启部分机器，留1台机器进行dump内存快照。
　　5）10分钟后，经分析快照，发现有个类ShopAddress占内存特别大，包含对象数150多万。
　　6）使用jstack命令（jstacklpid）查看JVM线程，搜索关键词ShopAddress，发现的确是有关于ShopAddress的堆栈信息。
　　7）基于堆栈信息找到对应的代码，修改代码并发布到生产环境，CPU终于降下来了。。。
　　2。场景简化回顾
　　假如说有这么一张表CREATETABLEtshopaddress（idint（11）unsignedNOTNULLAUTOINCREMENTCOMMENTid，shopidint（11）NOTNULLCOMMENTtshop。id，。。。）COMMENT门店地址；
　　需求是：需要根据多个shopid同时查询数据，于是某老6写了以下的代码publicListShopAddressselectByShopIdList（ListIntegershopIdList）｛WrapperShopAddresswrappernewEntityWrapper（）；wrapper。in（shopid，shopIdList）；ListShopAddressshopAddressListshopAddressMapper。selectList（wrapper）；returnshopAddressList；｝
　　就1个查询而已啊，有啥问题吗？
　　有啥问题吗？
　　Wrapper是mybatisORM框架用来组装sql类。翻译过来的sql应该是：selectfromtshopaddresswhereshopidin（？，？，？，。。。）；
　　即使tshopaddress表中存储了大量数据，只要shopIdList的数据量比较少，该查询都不会有问题。
　　但是今天突然有shopIdList〔〕传进来了，于是CPU便起飞了。。。
　　在mybatis的WrapperAPI中，如果value为null或者空列表的情况下，组装的sql会忽略该条件
　　从而导致上面的查询sql为：selectfromtshopaddress；
　　结果是全表查询，150多万的数据量，这就是JVM会疯狂进行FullGC的原因。3。预防措施
　　1）使用Wrapper查询之前增加每一个参数的非空校验，确保都是有值的。
　　2）避免使用Wrapper来组装条件查询数据库，尽量自己写sql，即时是shopidin（），最多也只是该业务报错，而不会导致整个系统垮掉。
　　但还是建议不要出现shopidin（）的情况，这个会报sql语法错误。可以增加11条件让sql正确执行并返回0条数据。
　　3）使用mybatis拦截器来统一限制查询条数，为每个查询增加limit限制，比如1次查询最多返回1000条结果，当触发limit限制的情况下可以告警。如果超过1000条，需要进行分页查询。
　　怎么样？还不赶快去看看你的项目，看看有没有老6给你留坑！！！