比较常见的死锁场景,并发批量update时的一个场景:
update cross_marketing
set gmtModified = NOW(),
pageview = pageview+ #extpageview#
WHERE marketingId=#marketingId#

 

第一次调用时,marketingId传入值顺序: 1,3,5,12
第二次调用时,marketingId传入值顺序:1,2,5,3
 
每次update时,会锁行。(一次批量操作为一个事务)
那么第一次调用时,顺序锁行,当更新完3,准备更新5的时候,发现5已经被第二次调用锁行了,就等待。而此时的第二次调用刚好更新完5准备去拿3的锁,却发现被第一次调用占有,于是就出现死锁。
 
所以,我们要在批量更新,更新操作的时候,按照一个固定的顺序来排序,然后进行操作。
前面的例子,如果按照marketingId从小到大排序,就会变成:
第一次调用时,marketingId传入值顺序: 1,3,5,12
第二次调用时,marketingId传入值顺序:1,2,3,5
如此,就避免了死锁的发生。

相关文章:

  • 2021-10-10
  • 2021-10-06
  • 2021-05-27
  • 2022-12-23
  • 2021-08-08
  • 2021-12-22
  • 2021-08-22
  • 2021-06-10
猜你喜欢
  • 2022-01-12
  • 2021-08-03
  • 2022-02-19
  • 2021-12-08
相关资源
相似解决方案