记录因Sharding Jdbc批量操作引发的一次fullGC( 二 ) _生活百科

接下来我们实验一下，改造前和改造后的 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】