最近遇到的并发问题

下面是这周遇到的一个并发的问题，虽然没有造成什么线上的问题，不过感觉还危险的，记录下，以免以后再出现类似的问题。

现象简介：

需求预发布验证的时候发现积分计算不正确。

问题定位：

首先查找应用所有相关的日志，没有有用的信息。积分计算这里也没有错误日志，说明不是程序报错引起的，而算分这里的逻辑之前项目中有详细的验证过，应该不会有问题。

 

好在积分计算这里有详细的日志，把两边日志进行详细的比对，发现应用对所有的处理都已经正确的进行调用，而处理方也已经正确的接受到所有的调用，所以定位到是处理方接受到调用之后处理的时候出现的问题。

 

问题分析：

这是审核记录之后的处理过程（简化），在没有并发的时候是正确的。

在批量审核的时候，因为是通过一个for循环，每次审核一条记录。而积分计算这里是通过异步线程来完成的，这样一个批量审核的积分计算可能会成为下面这个图里面这样

  假设这几个积分变动事件都是对会员A的凭证+1，则最后的处理可能是下面这个样子，两次+1操作，最后的结果却仅加了1，错误出现。

解决方案

1.    对这个代码模块增加synchronized(this)：这样会导致这个方法完全成了串行的，不同memberId也不可以并行执行，影响有点大

2.    用cache来解决这个问题，类似ConcurrentLock：不过这个是在credit里面，他们要用的话还得再搞一套

3.    直接用数据库的update xx set num=num+1这样的sql语句来保证不出现脏读和数据覆盖的问题。

 

最后确定使用第三种解决方案，一方面完全可以满足这里的需求且影响较小，另一方面改动成本也比较小。

 

Ps：

oracle在处理update xx set num=num+1之类的语句时，会加一个行级排它锁，保证在操作期间不会有并发问题。

这个自己试验了一下，启动两个客户端连到数据库，其中一个执行这样的语句，然后不commit，另一个客户端在执行同样的语句，就会一直卡在那里，直到前一个被commit。

 

After All

这个问题主要原因是没有考虑到并发带来的问题。希望大家以后遇到类似场景的时候可以考虑一下这些问题，tks!