• 记录因Sharding Jdbc批量操作引发的一次fullGC


    周五晚上告警群突然收到了一条告警消息,点开一看,应用 fullGC 了。

    于是赶紧联系运维下载堆内存快照,进行分析。

    内存分析

    使用 MemoryAnalyzer 打开堆文件

    mat 下载地址:archive.eclipse.org/mat/1.8/rcp…

    下载下来后需要调大一下 MemoryAnalyzer.ini 配置文件里的-Xmx2048m

    打开堆文件后如图:

    发现有 809MB 的一个占用,应该问题就出在这块了。然后点击 Dominator Tree,看看有什么大的对象占用。

    我们找大的对象,一级级往下点看看具体是谁在占用内存。点到下面发现是 sharding jdbc 里面的类,然后再继续往下发现了一个 localCache。

    原来是一个本地缓存占了这么大的空间

    为什么有这个 LocalCache 呢?

    带着这个疑惑我们去代码里看看它是怎么使用的,根据堆内存分析上的提示,我直接打开了 SQLStatementParserEngine 类。

    1. public final class SQLStatementParserEngine {
    2. private final SQLStatementParserExecutor sqlStatementParserExecutor;
    3. private final LoadingCache sqlStatementCache;
    4. public SQLStatementParserEngine(String databaseType, SQLParserRule sqlParserRule) {
    5. this.sqlStatementParserExecutor = new SQLStatementParserExecutor(databaseType, sqlParserRule);
    6. this.sqlStatementCache = SQLStatementCacheBuilder.build(sqlParserRule, databaseType);
    7. }
    8. public SQLStatement parse(String sql, boolean useCache) {
    9. return useCache ? (SQLStatement)this.sqlStatementCache.getUnchecked(sql) : this.sqlStatementParserExecutor.parse(sql);
    10. }
    11. }
    12. 复制代码

    他这个里面有个 LoadingCache 类型的 sqlStatementCache 对象,这个就是我们要找的缓存对象。

    从 parse 方法可以看出,它这里是想用本地缓存做一个优化,优化通过 sql 解析 SQLStatement 的速度。

    在普通的场景使用应该是没问题的,但是如果是进行批量操作场景的话就会有问题。

    就像下面这个语句:

    1. @Mapper
    2. public interface OrderMapper {
    3. Integer batchInsertOrder(List orders);
    4. }
    5. 复制代码
    1. <insert id="batchInsertOrder" parameterType="com.mmc.sharding.bean.Order" >
    2. insert into t_order (id,code,amt,user_id,create_time)
    3. values
    4. <foreach collection="list" item="item" separator=",">
    5. (#{item.id},#{item.code},#{item.amt},#{item.userId},#{item.createTime})
    6. </foreach>
    7. </insert>
    8. 复制代码

    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 情况。

    测试代码如下:

    1. @RequestMapping("/batchInsert")
    2. public String batchInsert(){
    3. for (int j = 0; j < 1000; j++) {
    4. List<Order> orderList = new ArrayList<>();
    5. int i1 = new Random().nextInt(1000) + 500;
    6. for (int i = 0; i < i1; i++) {
    7. Order order=new Order();
    8. order.setCode("abc"+i);
    9. order.setAmt(new BigDecimal(i));
    10. order.setUserId(i);
    11. order.setCreateTime(new Date());
    12. orderList.add(order);
    13. }
    14. orderMapper.batchInsertOrder(orderList);
    15. System.out.println(j);
    16. }
    17. return "success";
    18. }
    19. 复制代码

    GC 情况如图所示: 

    cache 里面存有元素: 

    修改代码后:

    1. @RequestMapping("/batchInsert")
    2. public String batchInsert(){
    3. for (int j = 0; j < 1; j++) {
    4. List<Order> orderList = new ArrayList<>();
    5. int i1 = new Random().nextInt(1000) + 500;
    6. for (int i = 0; i < i1; i++) {
    7. Order order=new Order();
    8. order.setCode("abc"+i);
    9. order.setAmt(new BigDecimal(i));
    10. order.setUserId(i);
    11. order.setCreateTime(new Date());
    12. orderList.add(order);
    13. }
    14. List<List<Order>> shard = ShardingUtils.shard(orderList);
    15. shard.stream().forEach(
    16. orders->{
    17. orderMapper.batchInsertOrder(orders);
    18. }
    19. );
    20. System.out.println(j);
    21. }
    22. return "success";
    23. }
    24. 复制代码

    GC 情况如下:

    cache 里面存有元素: 

    可以看出 GC 次数有减少,本地缓存的条数由 600 多减到了 11 个,如果导出堆内存还能看出至少降低了几百 M 的本地内存占用。

    另外,这个 cache 是有大小限制的,如果因为一个 sql 占了 600 多个位置,那么其他的 sql 的缓存就会被清理,导致其他 SQL 性能会受到影响,甚至如果机器本身内存不高,还会因为这个 cache 过大而导致频繁的 Full GC

    大家以后在使用 Sharding JDBC 进行批量操作的时候就需要多注意了

    另附上拆分为固定大小的数组的工具方法如下:

    1. public class ShardingUtils {
    2. private static Integer[] nums = new Integer[]{800,500,300, 200, 100, 50, 25, 10, 5, 2, 1};
    3. public static <T> List<List<T>> shard(final List originData) {
    4. return shard(originData, new ArrayList<>());
    5. }
    6. private static <T> List<List<T>> shard(final List originData, List> result) {
    7. if (originData.isEmpty()) {
    8. return result;
    9. }
    10. for (int i = 0; i < nums.length; i++) {
    11. if (originData.size() >= nums[i]) {
    12. List<T> ts = originData.subList(0, nums[i]);
    13. result.add(ts);
    14. List<T> ts2 = originData.subList(nums[i], originData.size());
    15. if (ts2.isEmpty()) {
    16. return result;
    17. } else {
    18. return shard(ts2, result);
    19. }
    20. }
    21. }
    22. return result;
    23. }
    24. }
  • 相关阅读:
    TypeScript & React(上)
    【论文阅读|深读】DNGR:Deep Neural Networks for Learning Graph Representations
    阿里云的流量价格表_2024阿里云服务器流量费用表
    Maven安装
    java.lang.reflect.Field 解读
    微信创意铃声定制,从铃声中找商机,轻松赚钱!
    springboot下使用rabbitMQ之开发配置方式(一)
    t2vec 辅助笔记:data_utils
    IDEA中如果优雅Debug
    图片转换成base64格式的优缺点
  • 原文地址:https://blog.csdn.net/m0_73311735/article/details/127749453