MyBatisPlus的in方法入参数量过多导致的JVM频繁FullGC案例

简介: MyBatisPlus的in方法入参数量过多导致的JVM频繁FullGC案例

 1.引子

在我们的认知中,通常认为MyBatisPlus的in方法入参数量超过1000条就会报错

//此方法当in中的字符超过1000就会报错
EntityWrapper ew = new EntityWrapper<>();
ew.in(TableFieldConstant.F_AUTH_RESULT_ID, ids);

image.gif

但如果入参数量达到上百万,那就会陷入循环中,导致虚拟机内存占用飙升,频繁GC,昨日我司生产环境就发生了这样的问题,先记录如下。

2.问题发现

线上监控组在pinpoint中发现2022-08-04 14:33:00的一个请求超时了,开始并没有太在意,只是要求业务部门去查询问题。

Request processing failed; nested exception is feign.RetryableException: Read timed out executing POST。。。。

image.gif编辑

3.故障分析

初步查看发现就是个Feign的远程调用超时,本想以网络闪断原因搪塞过去,但服务调用双方在同一台虚机上,用网络原因解释不了,觉得非常奇怪,就深入查找了一下问题。

3.1.首先查看线上两个服务的日志,并没有发现什么重要信息。

3.2.接下来看数据库,发现也正常。

3.3.再去看jvm的监控信息,果然发现了问题:

12:00-16:30左右jvm内存占用情况

image.gif编辑

12:00-18:30左右jvm内存占用情况

image.gif编辑

4号-5号的情况

image.gif编辑

可以看的非常清楚,之前的内存都很正常,后面内存占用一直很高,频繁进行FUllGC,很明显是发生了内存泄露。

3.4.jvm堆栈信息

请运维团队帮忙转存栈信息 jstack pid > pid.tdump

分析后发现该线程一直处于执行状态,导致内存一直没有得到释放。

image.gif编辑

 网上翻找资料,发现了相关的报告:

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;
        }
    }

image.gif

问题出现在

sqlStr = sqlStr.replace(String.format("{%s}", i), String.format("#{%s.paramNameValuePairs.%s}", this.getParamAlias(), genParamName));

image.gif

对replace测试发现当数据量大时替换会很耗时。而我们业务上并没有对这个入参的数量做限制。

image.gif编辑

Mybatisplus的in方法入参太多,会导致循环次数过多。

4.问题解决方案

4.1.控制入参数量

4.2.升级jar版本 3.x

我司采用方案1,发火线后问题解决

image.gif编辑

相关文章
|
7天前
|
SQL Java 数据库连接
【MyBatisPlus·最新教程】包含多个改造案例,常用注解、条件构造器、代码生成、静态工具、类型处理器、分页插件、自动填充字段
MyBatis-Plus是一个MyBatis的增强工具,在 MyBatis 的基础上只做增强不做改变,为简化开发、提高效率而生。本文讲解了最新版MP的使用教程,包含多个改造案例,常用注解、条件构造器、代码生成、静态工具、类型处理器、分页插件、自动填充字段等核心功能。
【MyBatisPlus·最新教程】包含多个改造案例,常用注解、条件构造器、代码生成、静态工具、类型处理器、分页插件、自动填充字段
|
1月前
|
前端开发 Java Apache
Springboot整合shiro,带你学会shiro,入门级别教程,由浅入深,完整代码案例,各位项目想加这个模块的人也可以看这个,又或者不会mybatis-plus的也可以看这个
本文详细讲解了如何整合Apache Shiro与Spring Boot项目,包括数据库准备、项目配置、实体类、Mapper、Service、Controller的创建和配置,以及Shiro的配置和使用。
312 1
Springboot整合shiro,带你学会shiro,入门级别教程,由浅入深,完整代码案例,各位项目想加这个模块的人也可以看这个,又或者不会mybatis-plus的也可以看这个
|
1月前
|
缓存 Java 数据库连接
使用MyBatis缓存的简单案例
MyBatis 是一种流行的持久层框架,支持自定义 SQL 执行、映射及复杂查询。本文介绍了如何在 Spring Boot 项目中集成 MyBatis 并实现一级和二级缓存,以提高查询性能,减少数据库访问。通过具体的电商系统案例,详细讲解了项目搭建、缓存配置、实体类创建、Mapper 编写、Service 层实现及缓存测试等步骤。
|
1月前
|
Java 应用服务中间件 程序员
JVM知识体系学习八:OOM的案例(承接上篇博文,可以作为面试中的案例)
这篇文章通过多个案例深入探讨了Java虚拟机(JVM)中的内存溢出问题,涵盖了堆内存、方法区、直接内存和栈内存溢出的原因、诊断方法和解决方案,并讨论了不同JDK版本垃圾回收器的变化。
30 4
|
1月前
|
Java
JVM进阶调优系列(5)CMS回收器通俗演义一文讲透FullGC
本文介绍了JVM中CMS垃圾回收器对Full GC的优化,包括Stop the world的影响、Full GC触发条件、GC过程的四个阶段(初始标记、并发标记、重新标记、并发清理)及并发清理期间的Concurrent mode failure处理,并简述了GC roots的概念及其在GC中的作用。
|
3月前
|
Java 数据库连接 Spring
后端框架入门超详细 三部曲 Spring 、SpringMVC、Mybatis、SSM框架整合案例 【爆肝整理五万字】
文章是关于Spring、SpringMVC、Mybatis三个后端框架的超详细入门教程,包括基础知识讲解、代码案例及SSM框架整合的实战应用,旨在帮助读者全面理解并掌握这些框架的使用。
后端框架入门超详细 三部曲 Spring 、SpringMVC、Mybatis、SSM框架整合案例 【爆肝整理五万字】
|
3月前
|
缓存 监控 算法
吃透 JVM 诊断方法与工具使用
【8月更文挑战第4天】深入了解并掌握JVM诊断需把握几大要点:1) 熟悉JVM内存模型,如堆、栈及方法区;2) 掌握垃圾回收机制与算法;3) 运用工具如`jps`(查看Java进程)、`jstat`(监控运行状态)、`jmap`(生成堆快照)、`jhat`(分析堆快照)、`jstack`(检查线程栈); 4) 利用专业工具如Eclipse Memory Analyzer分析堆转储文件查找内存泄漏; 5) 动态监控与调整JVM参数; 6) 结合日志分析性能瓶颈。通过实战案例加深理解,有效应对JVM性能问题。
|
4月前
|
算法 安全 Java
(七)JVM成神路之GC分代篇:分代GC器、CMS收集器及YoungGC、FullGC日志剖析
在《GC基础篇》中曾谈到过分代以及分区回收的概念,但基础篇更多的是建立在GC的一些算法理论上进行高谈阔论,而本篇则重点会对于分代收集器的实现进行全面详解,其中会涵盖串行收集器、并行收集器、三色标记、SATB算法、GC执行过程、并发标记、CMS收集器等知识,本篇则偏重于分析GC机制的落地实现,也就是垃圾收集器(Garbage Collector)。
111 8
|
4月前
|
监控 安全 Java
JVM内存问题之排查Direct Memory泄漏有哪些常用方法
JVM内存问题之排查Direct Memory泄漏有哪些常用方法
119 2
|
3月前
|
监控 JavaScript Java
JVM源码级别分析G1发生FullGC元凶的是什么
线上系统遭遇频繁Old GC问题,监控显示出现多次“to-space exhausted”日志,这表明垃圾回收过程中因年轻代 Survivor 区或老年代空间不足导致对象晋升失败。通过 JVM 源码分析,此问题源于对象转移至老年代失败时,JVM 无法找到足够的空间存放存活对象。进一步排查发现大对象分配占用了预留空间,加剧了空间不足的情况。使用 JFR 分析工具定位到定期报表序列化导致大量大对象生成,通过改用堆外内存进行序列化输出,最终解决了频繁 Old GC 问题。
117 0