代码常见小问题总结
-
涉及资金时的防刷、限量、防重（28）
长链路防重：
一个接口涉及到多个支付接口；根据统一的商户订单号，可以实现唯一订单号的幂等处理。可能出问题：调用支付新生产了支付订单号，然后一个商品订单产生了多个支付订单导致多次支付。
建议：a. 使用相同的业务订单号贯穿到最后的资金通路，避免重复资金操作；
b. 调用支付前生成订单号，先落地，再调第三方；重复处理时用上次生成的订单号直接支付。
c. 避免上游错误的依赖过多导致复杂度提升、如bosswlb.cfg送了之前相同流水号，导致实际未成功但上游认为成功，幂等时的响应区分重复成功交易及正常成功交易 -
交易判重处理
一般的交易系统，判重基本都是通过数据库的唯一索引判重。目前做法很多都是先查询库，如果记录为0，再执行后续操作。会导致高并发下性能；且有可能查询时不存在，入库时数据失败导致失败的问题。
建议：利用数据库的主键约束直接抛异常 -
库存问题避免不必要的悲观锁
在库存问题或者额度问题，用悲观锁锁先select...from...for udpate，然后判断剩余库存或额度是否足够，足够再取扣额度。导致高并发时由于锁的原因性能非常差
建议：a.利用数据库的行锁，update ... set stock=stock-buy_num where id=* and stock-buy_num>0，高并发下，如果库存不足更新失败，影响条数为0； b.秒杀等场景引入分布式锁或者队列 -
Spring的声明事务不生效问题
在项目中某些如更新数据库记录同时要记录操作日志的场景，需要把入库及更新做为一个事务。如果在我们的一个业务类中调用同一个类中加了@Transactional注解的方法，会发现事务不生效。
建议：Spring AOP无法切本类的方法，通过外部类调用该类加了@Transactional的目标方法。 -
索引不合理
有多列查询时建了多个单列索引，存在问题：多个单列索引占用更多空间，可能导致更新慢的问题；多个单列索引在多条件查询时优化器会选择最优索引策略，可能只有一个索引用上也可能多个索引都用上。
Mysql(5.7.20)
联合索引本质:当创建**(a,b,c)联合索引时，相当于创建了(a)单列索引，(a,b)的联合索引以及(a,b,c)的联合索引。
建议：a.数据量少的字段不需要加索引；b.避免使用or连接条件，如果or连接的条件，一个字段没有索引，就会放弃索引产生全表扫描；c.联合索引比每个列分别索引有优势；d.能用唯一索引就用唯一索引而不是普通索引。 -
bean中写成员变量导致线程不安全
在写业务逻辑时会因为一些参数传递问题在@service、@Compent等加了这些注解的类中添加成员变量。由于Spring的bean默认是单例的，从而导致高并发时的线程安全问题。
建议：Spring的bean中不要写成员变量 -
重复代码问题
项目中有大量重复代码主要会导致两个问题：a.修改时很容易修改一处忘记修改另外一处；b.代码并不是完全重复，而是相似度高，修改时容易改成一样从而改错。
建议：利用工厂模式+模板方法模式，消除重复代码 和if...else。 -
没有必要的public方法
代码中不需要声明为public的方法被声明为public，导致问题：a.后续代码不容易重构，因为不清楚方法被哪些类调用；b.不应该被访问的方法被访问了，引起生产问题。
建议：不确定是否需要public就不声明为public；一个.java文件只包含一个public类，可以有多个非public类。 -
关于性能压测：基于之前在我们项目组的压测经验，提供两个建议：a.关闭日志，即日志级别error后压测和之前对比；b.用arthas工具在测试环境检查各个方法的执行时间。
-
其它待整理注意代码点：
防刷：
短信接口被刷，重复多次调用的场景；
建议：平台资源，考虑单人限量、全局限量、流程识别、人机识别等手段；
限量：
因平台Bug有大量用户领取高额优惠券，并立即下单使用；
建议：有发放计划、申请批次，然后通过批量生产资产。达到限量、有审计、有追溯的目的。
多用组合少用继承
减少代码的侵入性
公共代码权限控制，应该单例但是代码没有控
对中间件的依赖，依赖过多导致复杂度提升、如redis、mq等
防sql注入
敏感数据保存
针对已有逻辑的优化改造的评判标准，优化前后系统可用性是否提高。理论上可分析
技术组件包@Bean需要扫描的问题，是否必要，开源包可参考的地方 -
参考 Java业务开发常见错误100例
-
关于我-张东涛，工作六年
网友评论