那些年那些神码

首先说明一下什么是神码？神码就是神奇代码的意思（也是糟糕的意思），在这里是为了表达引以为戒！

往事不堪回首！想当年（2017年）公司技术团队新组建，系统新搭建。为了赶工期，一切以快速为目标，快速试错，快速交付上线。项目管理规范被忽视和技术规范管控没有及时跟上，工程师们交付的代码质量非常的糟糕。产生了不少严重的生产故障，后果比较严重，教训惨痛！

当年虽是架构师岗位，但却像是救火队员。毫不夸张地说是，哪里有生产故障问题，哪里就得去救火！

原因有三：

• 团队新组建，成员水平参差不齐，有部分人还可以，但是有部分人基础确实不够硬，甚至不懂面向对象的人也来写java代码。
• 赶工期，项目管理没有做好，没有制定和执行统一的代码规范。
• 关键时刻容不得有半点怠慢，顶着巨大的压力，快速灭火救火才王道，使用问题影响最大化降低。

因此，在那些年救火过程中，填了不少的坑；事后复盘做了一些总结记录，针对问题进行深入分析，找出根因，希望避免再次出现，从而得到一些宝贵经验总结。

今天就来聊聊那些年给我曾经留下深刻教训的代码片断。在此不做批判，仅做反思与学习总结，也想让各位看官得到一点启发。下面我们来详细看看有哪些神码，到底有多神的代码？

神码片断1：不正确的使用redis命令

 

上面代码片断非常简单，就是简单封装的jedis工具类。初看也没有啥问题，但就因为这样代码导致生产出现奇怪的问题。生产环境部署多个业务系统，使用了同一个redis集群。某些业务系统的redis值被频繁清除，莫名其妙的丟失数据，排查很久之后才找出来。

最后通过redis后面服务监控，检查出来代码使用FlushALL命令，并通过全局搜索代码，找出来在某个业务系统退出登录的时候，调用了这个工具类。jedis工具类的init方法，init方法内部使用了flushAll命令，这个命令是会全库删除，非常坑的用法。当时是修改为flushdb（其实也有隐患的，如果多个应用或同个同个Redis db库，就会被刷掉）。

其实在用户退出的业务中，只需要清理相关对应的缓存就行了，即删除（del）对应的key值即可，完全没有必刷新动作。

 

神码片断2：不正确的使用Redis Key

各种条件组合在一起，作一个Redis Key，结果产生非常长的Key。

若这种大KEY太多，会比较占用较多的内存资源，查询效率也会变低，曾经这种又长又臭的串在我们系统出现过300多万个，导致查询效率下降，还曾经把服务搞死。

建议使用KEY Redis尽可能简短，如果实在太长怎么办？需要进行加工处理，如用hashCode 或md5处理一下。

另外通常不建议用"_"连接而是用“：”，冒号有一个好处有可以自动分目录结构，查询定位比较方便。重新改造一下代码。

下面还有一些曾经出现过不好正确的redis使用方法

（1）没有过期时间

看下面代码，是通用工具类方法！这样调用者写入redis之后就，key和value一直存在，久而久之redis就跑不动，毕竟空间靠内存撑着，空间是非常有限的。况且实际业务当中99%以上是需要有有效期，也即需要有设置过期时间的。

普通缓存放入，没有过期时间，是一种不好的实践！ 

（2）使用“*”星号模糊匹配

这种Key出现太多，会严重拖跨redis服务，redis查询这种key时候需要进行全表扫描，性能急速下降，所这种KEY方式慎用，最好不要用。

（3）把太多内容存入Redis

Redis存储容量有限的，在实际使用过程中，建议不要存入太大内容块，要控制一下。像这个KEY：DELIVERYEXCEPTIONMSG_LIST 内容有1.5GB，节点分片2GB内存，就吃掉了80%。

以上这些不正确使用方式，都曾经让我们吃过苦头，让redis崩过几次！所以请正确使用Redis，否则将会给你带来麻烦。

归根到底主要还是代码规范与质量控制不到位，开发人员不够自觉，写代码时随意性比强。

对于上述这些问题，我们可以统一封装一个Redis操作工具类，让开发人员直接调用。免得乱用带来不必要的问题。

如下面调用示例所示，RedisOpsProvider工具类已经封了Redis所有的基本操作，如果调用者不带过期时间，则默认一个相对经验过期时间如1天。

 

神码片断3：不正确的使用@Transactional 事务注解

在这里代码片断中使用了Spring @Transactional 事务注解。

这一段代码里有三个操作：

第一是写入主业务表 save(customer);

第二是把相关数据写入附件表记录登录save(attachment);

第三远程调用一外部接口sendCustomerToWeChat(customer);

第一和第二个使用事务可以实现事务一致性，但第三用了一个异步线程，同时也跨服务的远程调用

    CompletableFuture.supplyAsync(() -> {
            sendCustomerToWeChat(customer);
            return "OK";
        });

这里事务是不能保证数据一致性的。

 

神码片断4：加了分布式锁也出现重复编码

看到函数加了 @Transactional 事务注解，同时函数内部加锁了redis分布式锁  RedisLocker.lock(lockName); 按理应该正常产生业务编码，结果其实不然，已经加了redis全局锁，但还是出现重复编码的情况。

在高并发环境下可能会使用锁失效。正常做法是要么在事务外加锁，要么分解重写需要控制事务代码块。

锁失效的原因是：由于Spring的AOP，会在update/save方法之前开启事务，在这之后再加锁，当锁住的代码执行完成后，再提交事务，因此锁代码块执行是在事务之内执行的，可以推断在代码块执行完时事务还未提交；

其他线程进入锁代码块后，读取的库存数据不是最新的。

正确的做法要把最外层@Transactional 去掉。具体问题分析见《高并发环境下生成序列编码重复问题分析》。

 

神码片断5：跨服务调用数据列表导致内存溢出

 

公告列表查询逻辑非常简单，通过查出公告数据列表，再根据当前人所在的区域、组织、品牌品类、岗位进行数据集合的过滤。早期两个数据在同一个数据库上，用同一个服务，通过SQL 条件进行查询过滤，并不会有什么问题。

但后面微服务拆分之后，公告业务数据与人员架构分离成两个独立的应用服务，两个数据库。人员组织、权限是独立一个数据库，独立一个应用服务；公告业务数据又是独立的服务和数据库。

现在查询查询也跨多个服务间聚合才能展示最后的结果，也就是需要聚合两个服务list集合数据匹配过滤之后再进行结果的展示。

在大循环里面去查询部门、岗位、人员权限判断，然后通过远程RPC接口去调用人员接口数据。

每个人登录就将产生近1000次接口调用和本地数据业务查询组合，假定有1万人在使用，那意味着有1千万次远程调用，10万人访问，就有一亿次调用，面对巨大的网络IO，谁能扛得住，巨坑呀！

在测试环境测试的时候，访问人数少，没有测试出来，其实也是没有进行大规模的压测。

这一段代码上线后直接导致公告业务的服务应用内存溢出，服务死了好几次。坑死人不偿命！

阶段性优化修改：

循环调用之前，先把一些数据准备好，而不是进入循环里面去调用远程查询，减少跨机器的网络通讯时间和次数。优化改完之后，系统能正常运行，稳定下来了。

其实这种做法虽然阶段优化解决了问题，勉强过关，但仍然有很多改进优化的空间。

跨多个服务间调用：聚合——>条件过滤——>展示

多个List之间的聚合、遍历、拷贝，其实也消耗资源的，并发量高到一定程度，机器也承受不了。

优化方向转向使用ES，在发布公告即写入的时候就做一些平铺工作，把模板和权限逻辑做一些映射处理，查询的时候直接查询ES，然后做一些简单的标签符号替换，改造之后实现10万级别QPS，毫秒级响应。

ES改造后版本代码：

 

神码片断6：坑爹的类型判断

这种代码本质上代码规范问题，也是开发人员的基本素质问题。虽然不是什么致命问题，也产生正确的结果，但按照代码规范实在不应该这么写。

存在问题:

• 字符串比较不要用"=="而是用equals；
• 既然是判断是与否，就直接用boolean类型，增加代码可读性和健壮性;

稍微修改一下，不然真的无法看。

 

引申知识点：

基本数据类型它们之间用“==”比较时，比较的是它们的值。
引用数据类型它们用“==”比较时，比较的是它们堆内存地址。
Object equals()初始默认行为是比较对象的内存地址值，不过在String、Integer、Date等这些类中，equals都被重写以便用来比较对象的成员变量值是否相同，而不再是比较类的堆内存地址了。

看String equals JDK8源代码

对于Integer var = ? 在-128至127范围内的赋值，Integer对象是在IntegerCache.cache产生，会复用已有对象，对象引用地址是同一个，而这个区间之外的所有数据，都会在堆上直接产生新的对象。这是个大坑！！！

基本数据类型（如byte、short、char、int、long、float、double、boolean 等）的值比较，用 ”==” 进行比较。
引用数据类型（ 如String、Short、Char、Integer、Long、Float、Double、Boolean、Date等）的值比较，用equals进行比较。
推荐使用java.util.Objects#equals（JDK7引入的工具类）

 

神码片断7：万恶的where空条件

这段代码很简单，也很好理解，可是发布到生产环境却造成严重的灾难，可称得是史上最严重的BUG，下面详细描述一下这过程发生细节。

一、问题产生过程描述：

• 一个同手机号码用户（吴X兵）名下有多个账号，用户操作某些账号失效；
• 然后用失效账号登录，能正常登录到系统，继续做修改手机号码的动作；
• 修改手机号码时，由于程序查询逻辑不够严谨，主用户为空导致查询全表数据；
• 全部用户数据更新为同一个手机号码，问题暴发！
• 10：35左右发现UC系统比较卡，UC数据库有锁表时间过长告警，开发开始排查问题，11：20答疑收到终端用户（吴X兵）反馈收到很多（计审、价审）电话。
• 通过查询数据库、日志和链路定位到问题，12：30左右发布修复补丁，并从备份数据恢复数据（前一天凌晨3点的数据），并刷数补齐上午产生的数差。
• 1：30开始排查并修复各个业务产生的数据（服务单、设计软件任务列表、工厂订单、裂变活动、送货安装、MSCS订单）；
• 其中影响比较严重的是工厂订单，产生5万多条生产传单数据，其中2.5万多条流传到制造，准备到工厂车间排产。

二、详细排查问题记录

详细分析阿里云服务日志

2021-12-08 09:54:43.999

吴X兵一个正常B端用户登录我们平台，他在自己账号管理模块进行了解绑账号操作（ 账号：CZJR022@xx09243）本来就是一个很普通很正常的业务操作，他也如期正常的操作完了。

解除绑定操作正常成功之后，系统内部会进行调用清缓存接口，系统日志显示如下：

解绑成功能之后，主账号MainUserId被清除掉了。

2021-12-08 10:38:08.528  

吴X兵，又进行操作修改本人的手机号操作

结果悲剧正常产生了，就是开头那段代码，where条件为空，相当于查询全表！从链路日志也可以抓到这个SQL

开始出现批量更新手机号这个主用户手机号。库里所有其他的账号全部被更新为这个吴X兵的手机号码，呜呼！！！！

 

手机号码字段数据全量被更新为同一个，问题暴发之后，对此服务进行紧急灭火行动，对终端用户发布紧急停服通告，服务暂时挂起1小时进行数据修复。

由于这个服务没有做小时级别的数据增量备份，只能拿前一天数据凌晨3点的数据做数据库恢复，今天增量数据（900多条），只能通过解析系统日志，一条条从日志中找出来去匹配修复。

三、遗留的问题

• 部分设计文件写入PDF和XML的已经固化，设计文件无法做更新，只能重新发起重新生成，真是悲惨！
• 个别账号出现状态不一致情况，只能通过对比恢复前后数据进行更新刷数处理。

四、问题反思

• 失效的账号仍然能登录，这是程序的一个大BUG。
• 条件为空时查全表，需要大家吸取血的教训，举一反三，要求大家写程序时要严谨，加强自测，该加判断的不能少。

五、强化解决

• 框架层面解决无效当前用户全局拦截校验，阻断具体的业务操作；
• 加强代码，判空，非空，必填等核心逻辑代码对参数进行必要校验；
• 切面AOP全局拦截查询、更新、删除等全表操作的SQL，对无参进行拦截阻断；
• 重要数据质量安全监控，状态一致，数据一致性非常重要；
• 数据备份策略优化改进，重要数据按时段多几个备份。

经过这一次惨痛教训，决定在框架层做点功能，把不符合规则的SQL拦截掉，即不带where条件参数SQL进拦截，具体代码如下：

@Intercepts(
        {
                @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
        }
)
@Component
public class AllQueryInterceptor implements Interceptor {

    /**
     * 白名单：允许全表查询的表名
     */
    @Value("${white.table.name:}")
    private String whiteTableName;

    /**
     * 允许不带where条件，只带limit，且limit的最大条数
     */
    @Value("${limit.size:10000}")
    private Long limitSize;

    /**
     * 全局控制是否启动该校验的开关
     */
    @Value("${all.query.check:true}")
    private Boolean allQueryCheck;

    private static final Logger LOGGER = LoggerFactory.getLogger(AllQueryInterceptor.class);

    private static final Pattern p = Pattern.compile("\\s+");

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        MappedStatement mappedStatement = (MappedStatement) invocation.getArgs()[0];
        Object parameter = invocation.getArgs()[1];
        BoundSql boundSql = mappedStatement.getBoundSql(parameter);

        if(!sqlHavingWhere(boundSql) && !sqlHavingLimit(boundSql) && allQueryCheck){
            LOGGER.debug(boundSql.getSql());
            throw new BusinessException("检测到您有操作全表记录的风险，请联系系统管理员！");
        }else{
            return invocation.proceed();
        }
    }

    private Statement getStatement(String sql){
        Statement statement = null;
        try {
            statement = CCJSqlParserUtil.parse(sql);
        } catch (JSQLParserException e) {
            LOGGER.error("转换sql失败，原sql={}",sql);
        }
        return statement;
    }

    /**
     * 判断是否有limit
     * @param boundSql
     * @return
     */
    private Boolean sqlHavingLimit(BoundSql boundSql){
        try {
            IPage page = getPage(boundSql);
            if (null != page && page.getSize() >= 0L && page.getSize()<=limitSize){
                return true;
            }else {
                String originalSql = boundSql.getSql();
                return originalSql.contains(CommonConstants.SqlKeywords.LIMIT);
            }
        } catch (Exception e) {
            LOGGER.error("判断sql是否涉及全表操作异常，原因{}",e);
        }
        return true;
    }

    /**
     * 判断sql是否涉及全表操作
     * @param boundSql
     * @return
     */
    private Boolean sqlHavingWhere(BoundSql boundSql){
        try {
            String originalSql = boundSql.getSql();
            Statement stmt  = getStatement(originalSql);
            if(null != stmt){
                // 允许全量操作的表在白名单放开
                if(whiteTableName(getTableNames(stmt))){
                    return true;
                }
                // where没有条件或者只有一个删除标识条件，则认为是全表操作
                Set<String> where = getWhere(stmt);
                if(where == null){
                    LOGGER.debug("疑似操作全表的sql={}",originalSql);
                    return false;
                }else if(where!=null && where.size() == 1 && CommonConstants.SqlKeywords.DEL_FLAG.equals(where.iterator().next().toUpperCase())) {
                    LOGGER.debug("疑似操作全表的sql={}",originalSql);
                    return false;
                }
            }
        } catch (Exception e) {
            LOGGER.error("判断sql是否涉及全表操作异常，原因{}",e);
        }

        return true;
    }

    /**
     * 获取分页数据
     * @param boundSql
     * @return
     */
    private IPage getPage(BoundSql boundSql){
        Object paramObj = boundSql.getParameterObject();
        IPage<?> page = null;
        if (paramObj instanceof IPage) {
            page = (IPage)paramObj;
        } else if (paramObj instanceof Map) {
            Iterator var8 = ((Map)paramObj).values().iterator();

            while(var8.hasNext()) {
                Object arg = var8.next();
                if (arg instanceof IPage) {
                    page = (IPage)arg;
                    break;
                }
            }
        }
        return page;
    }

    /**
     * 获取表名
     * @param statement
     * @return
     */
    private List<String> getTableNames(Statement statement){
        List<String> tableNames = new ArrayList<>();
        if(statement != null){
            TablesNamesFinder tablesNamesFinder = new TablesNamesFinder();
            tableNames = tablesNamesFinder.getTableList(statement);
        }
        return tableNames;
    }

    /**
     * 判断表名是否在允许查全表的白名单内
     * @param tableNames
     * @return
     */
    private boolean whiteTableName(List<String> tableNames){
        for(String tableName : tableNames){
            // 有些表名带了``，把它去掉
            if(tableName.startsWith("`") && tableName.endsWith("`")){
                tableName = tableName.substring(1,tableName.length()-1);
            }
            if(whiteTableName.contains(tableName)){
                return true;
            }
        }
        return false;
    }

    private List<PlainSelect> getPlainSelect(Statement stmt){
        List<PlainSelect> plainSelectList = new ArrayList<>();
        Select select = (Select) stmt;
        SelectBody selectBody = select.getSelectBody();
        if(selectBody instanceof PlainSelect){
            PlainSelect plainSelect = (PlainSelect) selectBody;
            plainSelectList.add(plainSelect);
        }else{
            SetOperationList setOperationList = (SetOperationList)selectBody;
            for(SelectBody setOperation : setOperationList.getSelects()){
                PlainSelect plainSelect = (PlainSelect) setOperation;
                plainSelectList.add(plainSelect);
            }
        }
        return plainSelectList;
    }

    /**
     * 获取where里面的参数
     * @param
     * @return
     */
    private Set<String> getWhere(Statement stmt){
        Set<String> whereItemSet =new HashSet<>();
        List<PlainSelect> plainSelectList = getPlainSelect(stmt);
        for(PlainSelect plainSelect : plainSelectList){
            getWhereItem(plainSelect.getWhere(),whereItemSet);
        }
        return whereItemSet;
    }

    /**
     * 获取where节点参数
     * @param rightExpression
     * @param leftExpression
     * @param tblNameSet
     */
    private void getWhereItem(Expression rightExpression,Expression leftExpression,Set<String> tblNameSet){
        if(rightExpression != null){
            if (rightExpression instanceof Column) {
                Column rightColumn = (Column) rightExpression;
                tblNameSet.add(rightColumn.getColumnName());
            }if (rightExpression instanceof Function) {
                getFunction((Function) rightExpression,tblNameSet);
            }else {
                getWhereItem(rightExpression,tblNameSet);
            }
        }
        if(leftExpression != null){
            if (leftExpression instanceof Column) {
                Column leftColumn = (Column) leftExpression;
                tblNameSet.add(leftColumn.getColumnName());
            } if (leftExpression instanceof Function) {
                getFunction((Function) leftExpression,tblNameSet);
            }else {
                getWhereItem(leftExpression,tblNameSet);
            }
        }
    }

    /**
     * 获取where里面的字段
     * @param
     * @return
     */
    private void getWhereItem(Expression where, Set<String> tblNameSet){
        if(where instanceof BinaryExpression) {
            BinaryExpression binaryExpression = (BinaryExpression) where;
            Expression rightExpression = binaryExpression.getRightExpression() instanceof Parenthesis?((Parenthesis) binaryExpression.getRightExpression()).getExpression(): binaryExpression.getRightExpression();
            Expression leftExpression = binaryExpression.getLeftExpression() instanceof Parenthesis?((Parenthesis) binaryExpression.getLeftExpression()).getExpression(): binaryExpression.getLeftExpression();
            getWhereItem(rightExpression,leftExpression,tblNameSet);
        }else if(where instanceof Parenthesis){
            getWhereItem(((Parenthesis) where).getExpression(),tblNameSet);
        }else if(where instanceof InExpression){
            InExpression inExpression = (InExpression) where;
            Expression leftExpression = inExpression.getLeftExpression() instanceof Parenthesis?((Parenthesis) inExpression.getLeftExpression()).getExpression(): inExpression.getLeftExpression();
            getWhereItem(null,leftExpression,tblNameSet);
        }
    }

    /**
     * 获取select里面function里面的字段
     * @param function
     * @param selectItemSet
     * @return
     */
    private void getFunction(Function function, Set<String> selectItemSet){
        if(function.getParameters()==null || function.getParameters().getExpressions()==null){
            return;
        }
        List<Expression> list=function.getParameters().getExpressions();
        list.forEach(data->{
            if (data instanceof Function) {
                getFunction((Function)data,selectItemSet);
            }else if (data instanceof Column) {
                Column column = (Column) data;
                selectItemSet.add(column.getColumnName());
            }else{
                getWhereItem(data,selectItemSet);
            }
        });

    }

 

神码片断7：地狱式18层 if-else-for嵌套

 

像上面这种18层地狱式代码，看完是不是很想吐血！这里篇幅限制问题仅展示其中一小段，这种神码早些年我们旧项目中巨量存在。

这也是前人留下来宝贵的手笔，这种代码完全毫无设计，写这代码的人不讲武德，当时写这些代码的作者因为一些原因离职了，我们当年系统上线后将近一年多的时间里不敢去修改这神代码！自从接手那一天起，受尽各种艰难折磨，心中的苦只有自知，难受！

业务要增加需求吧，我们说这需求加不了，暂时搞不定，等系统重构版本出来之后再来提新需求。业务不理解天天诟病，天天叫骂，之前都可以的，怎么现在就不行了。哈！哈！哈！

业务反映的BUG吧，我们硬得头皮，只能再火坑里面加点油，花大量时间去研读作者的写作意图，然后小心奕奕做点局部修改，大家每次改完BUG心里，测试、发布、上线心里那个忐忑呀！

后面终于下大决心，对项目进行重构，经过两次大版本重构和多次的修正之后，终于把原来的项目代码仓库封存起当作纪念品！

确切地说我们是通过领域驱动设计方法，彻底解放了这种神码，变废为宝！具体怎么做的可以参考另一篇《我领域驱动设计的DDD》

 

总结

1、上面仅列了一小部分典型的神码，还有很多没贴出来；主要是经过多次重构设计之后，神码慢慢消失在历史长河之中。还希望各位看官们多总结多分享，并从中得一点启示。

2、实际工作中神码无处不在，在神码世界的里，你永远有可能收获意想不到的惊奇；为了减少工作中烦恼，为了美好的生活，写代码时候多点思考和设计。

3、一个复杂的项目往往由团队多人分工合作完的，团队需要建一套严格的代码规范约束，老鸟们多做codeReview，并贯彻始终，否则团队协作交付成果将大打折扣。

4、作为码农自身需要不断地加强武德修养，交付良品，拒绝交付废品；最直接的目的就一条为了不让后人鄙视和诟病就够了。