遇到个小BUG之后

用户3467126

发布于 2020-08-27 11:55:33

3360

发布于 2020-08-27 11:55:33

文章被收录于专栏：爱编码

事故开始

时间在回到一周前，测试跑过来跟我说：压测500w同步数据失败了。我保持以往的态度，莫慌莫慌，多大点事儿，然后打开运行日志，然后一看居然是内存不足,如下图：

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 12288 bytes for committing reserved memory.

做了那么久Java开发还是第一次遇到这种情况，然后free命令，查看一下服务器剩余内存，发现有5个G剩余，然后想一下，这不应该啊。然后自己也来测试一下，重新启动同步程序，一开始还是没有问题。过了10分钟后，Linux命令free查看剩余内存，10s钟刷新一下，内存消耗200M，到最后没有错10min钟后就跑蹦了。这时候我想了一下，应该遇到内存泄漏OOM了（真倒霉）。

第一次尝试

1.1、分析定位应用

从刚才的分析来看肯定是OOM导致的了，那要定位到底是哪个服务占用内存是一直飙升的。

Linux下运行如下命令可以查看，内存消耗最多的前10个进程：

ps auxw|head -1;ps auxw|sort -rn -k4|head -10

从图中基本锁定的了是第一个应用A或者第二个应用B

1.2、大数据量分小批次执行

查看运行日志后，发现A应用的数据库连接报错。mybatis进行批量update时报错了，打印了sql。这时候我的悬着的心突然放了下来，有种幸亏你报错了的感觉！！执行了打印的sql发现执行批量update操作1w条数据导致异常，估计是超时导致，但是该sql的where条件是主键，应该比较快的。所以现在只能降低数据量了，最终改为1000条数据进行操作速度就跟上了。改好问题然后测试环境执行一下，没有报错，内存也没有什么异常，下班！！！

第二天打开日志文件一看update还是报错，我擦傻眼了，服务又停了，又是内存溢出。

第二次尝试

服务B多线程通过fegin调用服务A中的接口，从服务A的报错日志来看是批量update导致mysql死锁的，然后搜索一下如何解决，类似如图：

发现了这位兄台的分析比较符合我的情况：https://www.cnblogs.com/pufeng/p/12069835.html

问题总结：应该是由于多线程同时修改同一条数据导致mysql死锁。比如你正在update某会员C的信息，另一条线程也在udpate该会员的信息这就会导致死锁。

2.1、加分布式锁

分布式锁的方式有很多，这里我的项目中用的jedis，各位可以自己搜索redis分布锁。类似逻辑如下

           boolean isLock = false;
            try {
                //调用路由服务同步数据
                while (!isLock) {
                    //获取分布式锁(20秒过期)
                    isLock = this.jedisClient.tryGetDistributedLock(RedisKey.CAS_SELLER_TRADES + sellerTable.getUserName(), sellerTable.getUserName(), 20);
                    try {
                        Thread.sleep(1000);
                    } catch (Exception e) {
                        logger.error("同步交易|获取分布式锁异常:" + e.getMessage());
                    }
                }
                long timeMillis = System.currentTimeMillis();
                 //TODO 执行业务，调用服务A中的同步接口
                  //***********************
                logger.info("同步交易|卖家账号:{}|调用路由同步数据耗时:{}毫秒", sellerTable.getUserName(), System.currentTimeMillis() - timeMillis);
            } catch (Exception e) {
                logger.error("同步交易|卖家账号:{}|线程异常:{}", sellerTable.getUserName(), ExceptionUtil.getStackTrace(e));
            } finally {
                //每条线程完成就释放
                if (isLock) {
                     this.jedisClient.releaseDistributedLock(RedisKey.CAS_SELLER_TRADES + sellerTable.getUserName(), sellerTable.getUserName());
                }
            }

然后重新执行应用程序，以为现在就应该ok了吧。但30分钟后，服务A居然还是停了，这次报错是关于fegin hystrix报错，结合日志打印的应该是服务接口处理时间过长（主要是入库update耗时），导致大量线程请求堆积到服务A接口。