posts - 206,  comments - 26,  views - 17万
< 2025年2月 >
26 27 28 29 30 31 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 1
2 3 4 5 6 7 8

假如两个线程同时修改数据库同一条记录,就会导致后一条记录覆盖前一条,从而引发一些问题。

例如:

  一个售票系统有一个余票数,客户端每调用一次出票方法,余票数就减一。

情景: 

  总共300张票,假设两个售票点,恰好在同一时间出票,它们做的操作都是先查询余票数,然后减一。

一般的sql语句:

  

复制代码
declare @count as int
 
begin tran
    select @count=count from ttt
    WAITFOR DELAY '00:00:05' --模拟并发,故意延迟5秒
    update ttt set count=@count-1
commit TRAN
 
SELECT * FROM ttt
复制代码

 

  问题就在于,同一时间获取的余票都为300,每个售票点都做了一次更新为299的操作,导致余票少了1,而实际出了两张票。

  打开两个查询窗口,分别快速运行以上代码即可看到效果。

 

定义解释:

  悲观锁:相信并发是绝大部分的,并且每一个线程都必须要达到目的的。

  乐观锁:相信并发是极少数的,假设运气不好遇到了,就放弃并返回信息告诉它再次尝试。因为它是极少数发生的。

 

悲观锁解决方案:

  

declare @count as int
 
begin tran
    select @count=count from tb WITH(UPDLOCK)
   WAITFOR DELAY '00:00:05' --模拟并发,故意延迟5秒
    update tb set count=@count-1
commit tran

 

  在查询的时候加了一个更新锁,保证自查询起直到事务结束不会被其他事务读取修改,避免产生脏数据。

  从而可以解决上述问题。

 

乐观锁解决方案:

 

复制代码
--首先给表加一列timestamp
 
ALTER TABLE ttt ADD timesFlag TIMESTAMP NOT null
 
然后更新时判断这个值是否被修改
declare @count as int
DECLARE @flag AS TIMESTAMP
DECLARE @rowCount AS int
begin tran
    select @count=COUNT,@flag=timesflag from ttt
    WAITFOR DELAY '00:00:05'
    update ttt set count=@count-1 WHERE timesflag=@flag --这里加了条件
    SET @rowcount=@@ROWCOUNT  --获取被修改的行数
commit TRAN
 
--对行数进行判断即可
 
IF @rowCount=1
    PRINT '更新成功'
ELSE
    PRINT '更新失败'
复制代码

 

  这便是乐观锁的解决方案,可以解决并发带来的数据错误问题,但不保证每一次调用更新都成功,可能会返回'更新失败'

 

悲观锁和乐观锁

  悲观锁一定成功,但在并发量特别大的时候会造成很长堵塞甚至超时,仅适合小并发的情况。

  乐观锁不一定每次都修改成功,但能充分利用系统的并发处理机制,在大并发量的时候效率要高很多。

posted on   努力--坚持  阅读(2038)  评论(0编辑  收藏  举报
(评论功能已被禁用)
编辑推荐:
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
阅读排行:
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)
点击右上角即可分享
微信分享提示