怎样避免多线程重复更新操作

背景：

​ 作为java后端的开发，我们对接APP、PCclient、Web时，可能会遇到一个问题那就是多端同一操作的并发，这样我们怎么解决呢？例如用户登录有用户自己的token并且有过期时间的，当token失效需要重新获取新的token。

分析：

​ 如果多端用的是一个用户token，怎么保证多端并发获取token是同一个呢？多端登录状态下token失效，多端同时请求换token接口，每一个请求都带有oldToken；如果我们是通过oldToken查出主键根据主键条件去更新已经过期token，这样**可能会导致死循环。为什么呢？**当多个接口同时访问数据库时，他们都可以通过oldToken查出过期的token的主键，并且可以都可以更新成功；每个端都更新一次token，那个token是有效的呢？

​ 问题解决思路：并发更新，一个更新成功，其余查出更新成功的token即可。

解决方案：

​ 由解决思路可以想到解决方案有两个种：第一，在接口里的更新token逻辑那一块添加锁，只能有一个线程获取锁成功，其余的等待释放锁；第二种：利用数据库更新时的行锁，保证只有一个更新SQL成功，其余的失败。

​ 代码层解决：单体部署的，很简单直接用synchronized修饰同步块和Lock 工具了加锁都可以；集群部署需要考虑多台机器，需要用到redis锁，多台机器竞争redis锁，谁获取成功谁执行。

​ 数据库层解决：在更新token时添加一个oldToken的条件，当第一次更新sql执行时，会将此行数据加锁，其他更新操作需要等待，当第一SQL执行完毕，oldToken数据已经不存在数据库中，所以后面的操作全部执行，但没有更新成功。

知识扩展：

​ 这一个简单的例子里面用到了两个知识点：编发编程三大特性和数据库隔离级别；代码层解决方案：是编发编程三大特性中的可见性，当一个线程改变一个值时，其他线程可以及时看到；数据库层解决方案：数据库常用的隔离级别是可重复读(在一个事务里若一个值的改变前后查询出的值都是为改变前的值)， 并发事务处理带来的问题，用事务隔离级别来解决。如果是并发业务量很大，建议在代码层解决并发出现的问题（这样不会把整个数据拖垮导致系统瘫痪），业务量不大可以将压力留给数据库。

并发编程文章
深入理解MySQL事务隔离级别与锁机制