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终于降下来了...
假如说有这么一张表
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的原因。
1)使用Wrapper查询之前增加每一个参数的非空校验,确保都是有值的。
2)避免使用Wrapper来组装条件查询数据库,尽量自己写sql,即时是shop_id in(),最多也只是该业务报错,而不会导致整个系统垮掉。
但还是建议不要出现shop_id in()的情况,这个会报sql语法错误。可以增加1<>1条件让sql正确执行并返回0条数据。
3)使用mybatis拦截器来统一限制查询条数,为每个查询增加limit限制,比如1次查询最多返回1000条结果,当触发limit限制的情况下可以告警。如果超过1000条,需要进行分页查询。
怎么样?还不赶快去看看你的项目,看看有没有老6给你留坑!!!