关于事务和锁的相互影响

基于Spring的项目使用@Transactional注解可以开启一段事务.

对于共享数据的操作需要进行加锁,无论是sychronized方法,lock代码块,或是借助redis标记位,加锁的概念基本等效.

事务和锁同时使用可能会产生一些问题,需要规避.

最简单暴力的做法是,锁的范围超过事务的范围: 事务开启前上锁,事务结束后释放锁,那么不会有相互影响的问题,但此方案锁的太重.

如果希望锁的粒度很小,此情况下,事务范围包含锁的范围,正常逻辑没有问题,锁会保护共享数据(数据库数据)的并发访问.但如果C阶段发生异常触发事务回滚,事务回滚操作是没有被锁约束的,因为B阶段结束,锁已经被释放.此时共享数据是可以被并发访问的,会带来未知的结果.

  解决方法之一是sql语句使用相对值的写法,比如对于库存数量的操作,sql语句写成 quantity = quantity + #{差值},如此,即使事务回滚,数据的最终值仍然是正确的. 

  以mysql为例,mysql的更新操作会加行级锁,多事务更新同一个行数据,只有前面一个事务结束(提交/回滚完成)时,后面的事务才能提交,所以相对值的写法quantity = quantity + #{差值},即使回滚不在锁的范围内,也不会影响到最终结果的正确的.

   其实即使业务层不加锁,mysql本身的事务机制,也可以保证数据的正确性,前提是用相对值的写法.但不应该过分依赖该机制,应该在业务层就进行上锁约束,提前避免并发冲突.