实习踩坑之路：一个ElasticSearchJava客户端的批量处理操作bulkIndexAsync引发的内存泄漏的血案

没错这又是一次血案，不过是在测试环境发现的，还好不是上次线上导致的CPU300%，这次及时发现，避免了线上血案，不过我还是要复盘一下的，下面就看看我的分析，看看有没有什么错误的地方

场景描述

场景很简单，就是把我MySQL中一个表的数据全部迁移到ElasticSearch的一个新索引上(因为老的索引字段匹配不上，随着业务迭代MySQL的字段类型发生了变化，ES又没有办法动态更新，所以最简单的方法就是同步一次数据啦)
然后我就想当然的写了一段同步脚本，然后满怀信心的去开发环境自测，没问题啊，10W多条数据很快啊，当时直接就同步完了，一条数据不差，心里暗想，这次真简单，然后就提测，去测试环境跑数据了，然后血案就发生了～～～～～～
跑着跑着，测试姐姐就说测试环境不能用了，我想着我只是同步一个表的数据，就算有错应该也只是影响那个页面的查询吧，然后我就打开了测试环境页面，好家伙，每个页面都报错了，都是can not found url，再结合我们的ShenYU网关，就想到应该是节点崩了，没有Controller注册到网关上，所以请求就没办法映射。然后我就去容器里面看报错嘛，但是错误显示的是超时：ElasticSearch连接超时，ZK连接超时等等等等。比较茫然，这个错误没有太大的信息呀，师兄提醒我是不是内存崩了，但是我并没有看到OOM的提醒呀，所以我就顺着这个思路开始了排查

思路验证

想到可能是OOM的原因，为了测验，我就把代码的异步批量处理改成了同步单条索引，然后去测试环境验证(为什么不去开发环境？我下面会说到)
发现如果是同步单条跑的话，一点问题没有就是速度有点慢，那不行，生产几千万呢，算下来的话，几天也同步不完，但是我从这就确定了应该是内存的问题：是内存溢出了？还是内存泄漏了？接下来，看看我经过排查过后得到的重点代码(罪魁祸首)

//拉取5000条数据
//这条SQL就是查询主键id > redis中已经同步过后的ID 的后5000条数据
//为了减轻MySQL压力
List<xxxDO> aDOS = xxxRepository.selectById(Integer.valueOf(redisService.get(idKey)));
//同步数据中间逻辑省略
//开始索引
xxxxEsService.indexEs(aDOS);


//再来看看这个indexEs方法
aDOS.forEach(aDO -> {
   
            EsABO esABO = new EsABO();
            //把aDO转换成esABO然后
            esHighLevelRestClient.bulkIndexAsync(Arrays.asList(esABO));
}
//罪魁祸手就是这个bulkIndexAsync接下来看看这个方法

 public void bulkIndexAsync(List<IDocument> dataList) {
   
        if (CollectionUtils.isEmpty(dataList