一个SQL错误的问题让我找到了公司框架中三个Bug-sql处理框架

本文是对之前开发中遇到的问题的一个总结，文章其实早就写好，但是觉得自己写得不够深入，就让文章一直躺在草稿箱里。昨天突然想起来了，就将文章重新修改了一下，还是发出来吧!

问题1

当时我在开发一个异常日志记录接口，其实业务流程很简单，就是前端提交错误日志到后台，后台接受到信息处理一番，然后插入数据库。因为这个接口的并发量比较高，为了不影响其他业务，并且同时提高响应的速度。于是采用 @Async 注解+ Spring线程池的方案来实现。线程池的配置如下：

<task:annotation-driven executor="jobExecutor"/>   
<task:executor id="jobExecutor" pool-size="20" queue-capacity="500" />

使用 task:annotation-driven/ 开启异步时，一定要记得配置executor属性，不然异步使用的线程池其实是

org.springframework.core.task.SimpleAsyncTaskExecutor ，但这个 SimpleAsyncTaskExecutor 不是真的线程池，这个类不重用线程，每次调用都会创建一个新的线程。

关键部分伪代码如下：

@Async  
 public void test(){  
  
     ExceptionLogEntity exceptionLogEntity = new ExceptionLogEntity();  
     exceptionLogEntity.setXX("");  
     exceptionLogEntity.setXXX("");  
     exceptionLogEntity.setIp("");  
     exceptionLogEntity.setUrl("");  
     exceptionLogEntity.setBusinessScene("");  
     exceptionLogEntity.setExceptionType("");  
     exceptionLogEntity.setExceptionDetailType("");  
     exceptionLogEntity.setExceptionMessage("");  
     exceptionLogEntity.setNoticeStatus("");  
     exceptionLogEntity.setCreateTime(new Date());  
     exceptionLogEntity.setUpdateTime(new Date());  
  
  
     ExceptionLogEntity insert = exceptionLogDao.insert(exceptionLogEntity);  
     log.info("实体的主键id=[{}]", insert.getId());  
  
 }

代码写完我简单的测试了一下，没啥问题后就告知前端可以对接了。可是奇怪的事情发生了，前端老铁告诉我接口有时会返回错误。我一听就感觉不对劲，心想这么简单的接口，我怎么可能有bug。于是我到日志平台上查询了一下日志，结果还真的是有问题。发现了一个SQL错误，具体错误如下(敏感信息已经处理)：

Caused by: java.lang.reflect.InvocationTargetException  
  
INSERT INTO `xx`(`xx`,`xx`,`ip`,`url`,`business_scene`,`exception_type`,`exception_detail_type`,`exception_message`,`notice_status`,`create_time`,`update_time`,`xx`,`member_phone`,`ip`,`url`,`business_scene`,`exception_type`,`exception_detail_type`,`exception_message`,`notice_status`,`create_time`,`update_time`) VALUES('','','','','','','','','','2020-01-08 19  
  
at sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source)  
  
--------------------------------------------  
  
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)  
  
at java.lang.reflect.Method.invoke(Method.java:498)  
  
at coderead.mybatis.log.JdbcCommonCollects$PreparedStatementHandler.invoke(JdbcCommonCollects.java:118)  
  
... 21 more  
  
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Column 'update_time' specified twice  
  
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)  
  
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)  
  
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)  
  
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  
  
at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)

复现问题

这个问题简单的来说就是SQL中的字段发生了重复， Column 'update_time' specified twice。其实不止update_time字段发生了重复，是很多字段都发生了重复。因为这个接口除了并发高一点之外，和其他的接口没有什么特别之处!突然我脑子里灵光一闪，难道是这个接口并发较高，导致框架在生成INSERT类型的SQL发生了错误???要是这样的话，我直接创造一个这样的场景不就可以实现了嘛!然后我写下了下面的代码：

public void test(){  
  
        for (int i = 0; i < 1000; i++) {  
            ExceptionLogEntity exceptionLogEntity = new ExceptionLogEntity();  
            exceptionLogEntity.setXX("");  
            exceptionLogEntity.setXXX("");  
            exceptionLogEntity.setIp("");  
            exceptionLogEntity.setUrl("");  
            exceptionLogEntity.setBusinessScene("");  
            exceptionLogEntity.setExceptionType("");  
            exceptionLogEntity.setExceptionDetailType("");  
            exceptionLogEntity.setExceptionMessage("");  
            exceptionLogEntity.setNoticeStatus("");  
            exceptionLogEntity.setCreateTime(new Date());  
            exceptionLogEntity.setUpdateTime(new Date());  
  
            Thread thread = new Thread(() -> {  
                exceptionLogDao.insert(exceptionLogEntity);  
            });  
  
            thread.start();  
        }  
    }

代码写完直接重启项目，最后一触发上面的代码。果然，同样的错误又出现了。这里我先介绍下使用的ORM框架：

此ORM框架是集团O2O研发中心研发的基础组件，提供同Mybatis一样的功能：只需定义接口，无需写实现类。此外，对单表操作还封装了一套常用的增删改查处理，连接口也无需再定义，对开发人员非常友好，大大降低了冗长的jdbc操作代码量，提升了开发效率。

我问了问旁边的同事，在使用公司的ORM框架自带的INSERT方法时，有没有遇到SQL列重复的问题吗?嘿你还别说，大家异口同声说遇到过。那厉害了，看来这真的不是个别现象，真的是框架的bug。于是乎我花了一点时间来找找看到底是在哪个地方出现了问题，皇天不负有心人我还真的找到了，具体的代码如下：

public List<DalColumn> getDalColumnsWithoutId() {  
    if (this.columnsWithoutId != null) {  
        return this.columnsWithoutId;  
    } else {  
        this.columnsWithoutId = new ArrayList(this.dalColumns.size() - 1);  
        Iterator var1 = this.dalColumns.iterator();  
  
        while(var1.hasNext()) {  
            DalColumn column = (DalColumn)var1.next();  
            if (!column.isIdColumn()) {  
                this.columnsWithoutId.add(column);  
            }  
        }  
  
        return this.columnsWithoutId;  
    }  
}

问题就出在 columnsWithoutId 上，它的类型是 List ，是所在类的一个属性默认为null，保存的是一个表除主键ID之外的所有字段。上面的代码在单线程情况下没有问题，但是在多线程的情况下就问题大了。 columnsWithoutId 在多线程情况下就是一个线程共享变量，假设在某个时机有多个线程恰好执行到 if 代码块，发现 columnsWithoutId 的值为null，则就会同时执行 else代码块，那这时就会执行多次循环，自然 columnsWithoutId 中的字段就会出现了重复。

解决问题

这个问题已经找到，那接下来就差一个解决方案了。

官方修复

我当时想既然这个框架是公司研发中心提供的基础组件，那就是说明在公司内部会有很多项目组使用，问题说不定早就被修复了。你还别说在公司的wiki上我还真的找到了，有位负责这个组件的大佬在wiki上分享了”单表插入偶发列重复问题定位与解决”的文章。(文章地址我就不发了，公司内部地址发出来你们也访问不了)文章里详细的描述了问题发生的场景(和我上面描述的差不多)、问题定位过程还有解决方案。摘选文章上的解决方案：

明确了是线程安全的问题，解决方案就好确定了，解决线程安全有三种方案：

方案一：互斥同步——synchronized,ReentrantLock

方案二：非阻塞同步——CAS

方案三：无同步方案:——ThreadLocal

结合业务场景，综合分析，最终确认使用方案一，采用synchronized关键字，使用双重检查锁的方式解决此问题。

大佬已经将bug修复并发布了新版本到Maven仓库，项目中有发生上述问题的，直接升级对应的组件版本即可。既然官方已经给出了解决方案，我直接升级项目中的组件版本号就行了。结果我一更换项目中的版本，我的项目就再也没有启动起来。研究发现，组件版本相差太多，很多依赖发生了冲突。我项目中使用的是 1.1.6-RELEASE ,问题官方在版本 2.1.0-RELEASE 中修复。这组件版本差距太大贸然升级肯定是有很大的风险了，于是我放弃了!

另辟蹊径解决

既然你自带的插入方法有问题，我直接自定义一个插入方法不就得了。惹不起我还躲不起么!我最后又问了同事们最后都是怎么解决的，大家也都说是自定义SQL，而且都不再用框架自带的方法了，大家都很聪明呀!(其实这个还有后续，后面有一期开发过程中，需要用到批量插入的功能，我又偷懒用了框架自带的batch方法，又把我给坑了。从那之后，我再也没有用自带的方法了……)

问题2

我在排查上面的问题的时候，在框架里面看到了下面的代码：

private Number execute4PrimaryKey(String sqlId, Map<String, Object> paramMap, KeyHolder keyHolder) {  
    long startTimestamp = System.currentTimeMillis();  
    String sql = null;  
  
    Object var8;  
    try {  
        MappedStatement mappedStatement = this.configuration.getMappedStatement(sqlId, true);  
        mappedStmtThreadLocal.set(mappedStatement);  
        sql = mappedStatement.getBoundSql(paramMap);  
        int result = false;  
        int result;  
        if (keyHolder != null) {  
            this.execution.update(sql, new MapSqlParameterSource(DalUtils.mapIfNull(paramMap)), keyHolder);  
            result = keyHolder.getKey() == null ? 0 : keyHolder.getKey().intValue();  
        } else {  
            result = this.execution.update(sql, DalUtils.mapIfNull(paramMap));  
        }  
  
        Integer var9 = result;  
        return var9;  
    } catch (Exception var13) {  
        this.throwException(var13);  
        var8 = null;  
    } finally {  
        mappedStmtThreadLocal.remove();  
        logger.debug("{} method:{}, sql:{}, param:{}", new Object[]{this.logPrefix, "execute", sql, paramMap});  
        this.logProfileLongTimeRunningSql(startTimestamp, sql, paramMap);  
    }  
  
    return (Number)var8;  
}

大家仔细看看，这上面的代码有个不容易发现的问题。问题是这样的，我们系统中表的主键类型定义的都是 bigint ,这个类型对应的是Java中的 Long 类型，说到这大家明白了么?对了，就是数据溢出的问题。

复现问题

我将表中的主键自增量设置为Java Int类型的最大值+1，也就是2147483648。然后数据库再新增一条记录，此时表中记录的主键是2147483648，但Java实体中的主键ID已经是个负数-2147483648了。

使用Long类型时，要注意JavaScript接收后端Long类型数据精度丢失问题

解决问题

这个问题还真不好另辟蹊径了，只能后面出现类似的问题，升级ORM框架的版本了。

问题3

其实这个问题我应该在看那篇内部文章的时候就应该发现的，但我当时就是没有看出来!此时的我留下了没有技术的泪水。对于问题1，当时那位大佬最终采用 synchronized 进行加锁解决多线程情况下共享变量读写问题，具体代码如下(敏感信息打码)：

修改前的代码：

public List<DalColumn> getDalColumnsWithoutId() {  
        if (this.columnsWithoutId != null) {  
            return this.columnsWithoutId;  
        } else {  
            this.columnsWithoutId = new ArrayList(this.dalColumns.size() - 1);  
            Iterator var1 = this.dalColumns.iterator();  
  
            while(var1.hasNext()) {  
                DalColumn column = (DalColumn)var1.next();  
                if (!column.isIdColumn()) {  
                    this.columnsWithoutId.add(column);  
                }  
            }  
  
            return this.columnsWithoutId;  
        }  
    }

修改后的代码(引用文章中的代码截图)：

问题复现

这个问题要复现的话，不太好复现，因为情况是比较极端的，但是在复杂的生产环境还是很可能出现的。

举例说明：

假设有A、B两个线程，A线程执行到for循环处，B线程恰好执行到最开始的if判断处，由于此时的cloumnsWithId已经被A线程赋值，肯定不为null，然后线程B就直接返回了，导致B线程调用者获得了一个空的或者保存部分字段的cloumnsWithId。这种情况最终导致的结果是INSERT SQL中的字段缺失。

解决办法

对于多线程下的共享变量，我们一定要坚持读读可并行，读写要排队的原则。当然能不加锁的话，也是不错的选择。

我发现这个问题之后，就找到了前文中说的大佬，跟他反馈了我的想法，并提出我的解决方案。

直接在 getDalColumnsWithoutId 方法上添加 synchronized 。
修改第一个if判断逻辑，然后使用 synchronized 锁代码块。

public List<DalColumn> getDalColumnsWithoutId() {  
    int size = CollectionUtils.size(this.dalColumns);  
    if (CollectionUtils.size(this.columnsWithoutId) == size && size > 0 ) {  
        return this.columnsWithoutId;  
    }  
    synchronized(lock){  
        if (columnsWithoutId == null) {  
            columnsWithoutId = new ArrayList<>(size*2);  
        }  
        for (DalColumn column :  this.dalColumns){  
            if (!column.isIdColumn()) {  
                this.columnsWithoutId.add(column);  
            }  
        }  
    }  
    return this.columnsWithoutId;  
}

当时与大佬的沟通截图，来自大佬的肯定：

总结

在遇到问题的时候不要着急，一定要学会大胆假设，然后小心求证。要勇敢地质疑权威，不要认为既然已经是框架了就没有bug。例如Spring从当初的1.0到现在版本号都超过5.0了，除了给Spring增加新的功能，其他的升级就是在修复Spring中的bug。做出自己的假设之后，就要进行场景复现，一个正常的bug是可以不断地被复现的。复现了问题那就是找到问题的症结所在，剩下的就是如何去解决啦!