Sharding Jdbc批量操作引发fullGC解决
正文
周五晚上告警群突然收到了一条告警消息，点开一看，应用 fullGC 了。
于是赶紧联系运维下载堆内存快照，进行分析。
内存分析
使用 MemoryAnalyzer 打开堆文件
mat 下载地址：https://www.jb51.net/zt/matlab.html
下载下来后需要调大一下 MemoryAnalyzer.ini 配置文件里的-Xmx2048m
打开堆文件后如图：
发现有 809MB 的一个占用，应该问题就出在这块了。然后点击 Dominator Tree，看看有什么大的对象占用。
我们找大的对象，一级级往下点看看具体是谁在占用内存。点到下面发现是 sharding jdbc 里面的类，然后再继续往下发现了一个 localCache。
原来是一个本地缓存占了这么大的空间
为什么有这个 LocalCache 呢？
带着这个疑惑我们去代码里看看它是怎么使用的，根据堆内存分析上的提示，我直接打开了 SQLStatementParserEngine 类。
public final class SQLStatementParserEngine {
private final SQLStatementParserExecutor sqlStatementParserExecutor;
private final LoadingCache<String, SQLStatement> sqlStatementCache;
public SQLStatementParserEngine(String databaseType, SQLParserRule sqlParserRule) {
this.sqlStatementParserExecutor = new SQLStatementParserExecutor(databaseType, sqlParserRule);
this.sqlStatementCache = SQLStatementCacheBuilder.build(sqlParserRule, databaseType);
}
public SQLStatement parse(String sql, boolean useCache) {
return useCache ? (SQLStatement)this.sqlStatementCache.getUnchecked(sql) : this.sqlStatementParserExecutor.parse(sql);
}
}
他这个里面有个 LoadingCache 类型的 sqlStatementCache 对象，这个就是我们要找的缓存对象。
从 parse 方法可以看出，它这里是想用本地缓存做一个优化，优化通过 sql 解析 SQLStatement 的速度。
在普通的场景使用应该是没问题的，但是如果是进行批量操作场景的话就会有问题。
就像下面这个语句：
@Mapper
public interface OrderMapper {
Integer batchInsertOrder(List<Order> orders);
}
<insert id="batchInsertOrder" parameterType="com.mmc.sharding.bean.Order" >
insert into t_order (id,code,amt,user_id,create_time)
values
<foreach collection="list" item="item" separator=",">
(#{item.id},#{item.code},#{item.amt},#{item.userId},#{item.createTime})
</foreach>
</insert>
1）我传入的 orders 的个数不一样，会拼出很多不同的 sql，生成不同的 SQLStatement，都会被放入到缓存中
2）因为批量操作的拼接，sql 本身长度也很大。如果我传入的 orders 的 size 是 1000，那么这个 sql 就很长，也比普通的 sql 更占用内存。
综上，就会导致大量的内存消耗，如果是请求速度很快的话，就就有可能导致频繁的 FullGC。
解决方案
因为是参数个数不同而导致的拼成 Sql 的不一致，所以我们解决参数个数就行了。
我们可以将传入的参数按我们指定的集合大小来拆分，即不管传入多大的集合，都拆为{300, 200, 100, 50, 25, 10, 5, 2, 1}这里面的个数的集合大小。如传入 220 大小的集合，就拆为[{200},{10},{10}]，这样分三次去执行 sql，那么生成的 SQL 缓存数也就只有我们指定的固定数字的个数那么多了，基本不超过 10 个。
接下来我们实验一下，改造前和改造后的 gc 情况。
测试代码如下：
@RequestMapping("/batchInsert")
public String batchInsert(){
for (int j = 0; j < 1000; j++) {
List<Order> orderList = new ArrayList<>();
int i1 = new Random().nextInt(1000) + 500;
for (int i = 0; i < i1; i++) {
Order order=new Order();
order.setCode("abc"+i);
order.setAmt(new BigDecimal(i));
order.setUserId(i);
order.setCreateTime(new Date());
orderList.add(order);
}
orderMapper.batchInsertOrder(orderList);
System.out.println(j);
}
return "success";
}
GC 情况如图所示：
cache 里面存有元素：
修改代码后：
@RequestMapping("/batchInsert")
public String batchInsert(){
for (int j = 0; j < 1; j++) {
List<Order> orderList = new ArrayList<>();
int i1 = new Random().nextInt(1000) + 500;
for (int i = 0; i < i1; i++) {
Order order=new Order();
order.setCode("abc"+i);
order.setAmt(new BigDecimal(i));
order.setUserId(i);
order.setCreateTime(new Date());
orderList.add(order);
}
List<List<Order>> shard = ShardingUtils.shard(orderList);
shard.stream().forEach(
orders->{
orderMapper.batchInsertOrder(orders);
}
);
System.out.println(j);
}
return "success";
}
GC 情况如下：
cache 里面存有元素：
可以看出 GC 次数有减少，本地缓存的条数由 600 多减到了 11 个，如果导出堆内存还能看出至少降低了几百 M 的本地内存占用。
另外，这个 cache 是有大小限制的，如果因为一个 sql 占了 600 多个位置，那么其他的 sql 的缓存就会被清理，导致其他 SQL 性能会受到影响，甚至如果机器本身内存不高，还会因为这个 cache 过大而导致频繁的 Full GC
大家以后在使用 Sharding JDBC 进行批量操作的时候就需要多注意了
另附上拆分为固定大小的数组的工具方法如下：
public class ShardingUtils {
private static Integer[] nums = new Integer[]{800,500,300, 200, 100, 50, 25, 10, 5, 2, 1};
public static <T> List<List<T>> shard(final List<T> originData) {
return shard(originData, new ArrayList<>());
}
private static <T> List<List<T>> shard(final List<T> originData, List<List<T>> result) {
if (originData.isEmpty()) {
return result;
}
for (int i = 0; i < nums.length; i++) {
if (originData.size() >= nums[i]) {
List<T> ts = originData.subList(0, nums[i]);
result.add(ts);
List<T> ts2 = originData.subList(nums[i], originData.size());
if (ts2.isEmpty()) {
return result;
} else {
return shard(ts2, result);
}
}
}
return result;
}
}
以上就是Sharding Jdbc批量操作引发fullGC解决的详细内容，更多关于Sharding Jdbc引发fullGC的资料请关注脚本之家其它相关文章！
相关文章
下面小编就为大家带来一篇Java 关键字 速查表介绍。小编觉得听不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧2017-04-04
MyBatisPlus 一对多、多对一、多对多的完美解决方案
这篇文章主要介绍了MyBatisPlus 一对多、多对一、多对多的完美解决方案,本文通过图文并茂的形式给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下2020-11-11
这篇文章主要介绍了Java中Elasticsearch的核心概念详解,Elasticsearch 是一个分布式、免费和开放的搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据,需要的朋友可以参考下2023-07-07
这篇文章主要介绍了Flowable历史查询实例分析,历史是记录流程执行过程中发生的事情,并将其永久存储的组件,与运行时数据不同,历史数据在流程实例完成以后仍保存在数据库中,下面我们来深入了解2023-10-10
Spring中@Autowired和@Resource注解的使用区别详解
这篇文章主要介绍了Spring中@Autowired和@Resource注解的使用区别详解,@Autowired默认根据type进行注入,找到与指定类型兼容的 Bean 并进行注入,如果无法通过type匹配到对应的 Bean 的话,会根据name进行匹配,如果都匹配不到则抛出异常,需要的朋友可以参考下2023-11-11
java.net.UnknownHostException异常的一般原因及解决步骤
关于java.net.UnknownHostException大家也许都比较熟悉,这篇文章主要给大家介绍了关于java.net.UnknownHostException异常的一般原因及解决步骤,文中通过代码介绍的非常详细,需要的朋友可以参考下2024-02-02
本文主要介绍了Mybatis-Plus通过SQL注入器实现批量插入的实践，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2022-08-08
这篇文章主要介绍了java多线程如何按指定顺序同步执行,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下2019-10-10
这篇文章主要介绍了JRebel在线激活破解实现教程,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下2020-12-12
EJB轻松进阶之一...2006-12-12
最新评论