后端开发常犯的问题（Java版）

数据类型使用不当

——钱相关的计算，数据类型必须用BigDecimal

1.很多开发在做金额计算时会使用double数据类型，自测一些常用场景认为double是满足需求的因而图省事直接使用此数据类型。使用double类型存在金额精度丢失的风险，涉及到钱的数据类型必须使用BigDecimal

2.数据类型转换精度丢失，上游使用double类型，接受数据后直接转换为BigDecimal，导致数据精度丢失

缺少必要的校验，默认调用方会参照约定进行调用

——必传参数，重要参数逻辑，涉及权限逻辑必须有拦截校验 

1.必传参数未做空校验以及字段值未做正确性校验，开发会以与上游约定好的应该怎么传参为理由不做校验。需求和人员一直是变动的，不能保证传参不出错，所以重要参数需要做校验

2.与权限相关的场景，所有接口都需要做权限校验的接口。 比如新用户可以选择领取礼品的场景，一般分为两个接口实现，1）用户是否为新用户，若为新用户则返回可以领取礼品；2）用户选择礼品后给用户发放礼品。有些开发会只在查询接口中做用户是否是新用户的校验，而在真正的发奖接口中不做校验。这样会有资损的风险，用户可以抓包直接获取到发奖接口给用户领取新用户礼品，所以在与权限相关的场景中，所有的接口都需要做权限的校验

RPC接口jar包升级影响了调用方

1.新增字段等操作不当，导致调用方序列化失败

并发场景未考虑

 1.依赖client服务的并发限制，使用client加锁保证调用接口串行，服务端并没有加锁，接口超时等异常场景client重试，服务端产生了并发问题

2.事务理解不正确，虽然使用了事务，还是出现了数据被覆盖的问题

举例：银行取钱业务

##事务开始##
1.查询用户A的账户信息：select * from account where user = A；
2.计算用户A的账户余额
3.更新用户A的账户余额：update acount set money=? where user = A;
##事务提交##

用户连续取钱两次，如下图所示，后面运行的事务的值会将前面修改的值覆盖掉

事务A1	事务A2
启动事务
查询得到值10	启动事务
	查询得到值10
将10改成8
	将10改成7
提交事务
	提交事务

正确做法：

查询数据的SQL添加写锁

小知识：

1.锁在事务commit后才会释放

2.在同一个事务中，锁被同一个事务的SQL语句共享

使用catch进行代码逻辑区分

——这个是我没有想到的，竟然还有用异常来区分不同的逻辑的。

因为代码的变迁，某个字段A的值的类型有多个，代码中用变量X承接字段A，X的类型为字段A的一个类型，如果字段A是其他类型，赋值就会报错，RD用try catch来解决，将A另外一种类型的处理逻辑写在catch代码块中执行。

虽然这么写也没有什么问题，但是发生异常时，jvm需要保存异常栈，内存占用和执行效率会远远大于增加一个if调用的

持续更新中。。。