1.引子
在我们的认知中，通常认为MyBatisPlus的in方法入参数量超过1000条就会报错
//此方法当in中的字符超过1000就会报错
EntityWrapper ew = new EntityWrapper<>();
ew.in(TableFieldConstant.F_AUTH_RESULT_ID, ids);但如果入参数量达到上百万，那就会陷入循环中，导致虚拟机内存占用飙升，频繁GC，昨日我司生产环境就发生了这样的问题，先记录如下。
2.问题发现
线上监控组在pinpoint中发现2022-08-04 14:33:00的一个请求超时了，开始并没有太在意，只是要求业务部门去查询问题。
Request processing failed; nested exception is feign.RetryableException: Read timed out executing POST。。。。
3.故障分析
初步查看发现就是个Feign的远程调用超时，本想以网络闪断原因搪塞过去，但服务调用双方在同一台虚机上，用网络原因解释不了，觉得非常奇怪，就深入查找了一下问题。
3.1.首先查看线上两个服务的日志，并没有发现什么重要信息。
3.2.接下来看数据库，发现也正常。
3.3.再去看jvm的监控信息，果然发现了问题：
12:00-16:30左右jvm内存占用情况
12:00-18:30左右jvm内存占用情况
4号-5号的情况
可以看的非常清楚，之前的内存都很正常，后面内存占用一直很高，频繁进行FUllGC，很明显是发生了内存泄露。
3.4.jvm堆栈信息
请运维团队帮忙转存栈信息 jstack pid > pid.tdump
分析后发现该线程一直处于执行状态，导致内存一直没有得到释放。
网上翻找资料，发现了相关的报告：
https://blog.csdn.net/cuixinzhou/article/details/113030993
初步判定是mybatis-plus的使用不当导致的。
protected String formatSqlIfNeed(boolean need, String sqlStr, Object... params) {
if (need && !StringUtils.isEmpty(sqlStr)) {
if (ArrayUtils.isNotEmpty(params)) {
for(int i = 0; i < params.length; ++i) {
String genParamName = "MPGENVAL" + this.paramNameSeq.incrementAndGet();
sqlStr = sqlStr.replace(String.format("{%s}", i), String.format("#{%s.paramNameValuePairs.%s}", this.getParamAlias(), genParamName));
this.paramNameValuePairs.put(genParamName, params[i]);
}
}
return sqlStr;
} else {
return null;
}
}问题出现在
sqlStr = sqlStr.replace(String.format("{%s}", i), String.format("#{%s.paramNameValuePairs.%s}", this.getParamAlias(), genParamName));
对replace测试发现当数据量大时替换会很耗时。而我们业务上并没有对这个入参的数量做限制。
Mybatisplus的in方法入参太多，会导致循环次数过多。
4.问题解决方案
4.1.控制入参数量
4.2.升级jar版本 3.x
我司采用方案1，发火线后问题解决
