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，发火线后问题解决