悲观锁与乐观锁的一些使用

  1 首先我们来了解一下 乐观锁与悲观锁的区别
  2 
  3 乐观锁的思路一般是表中增加版本字段，更新时where语句中增加版本的判断，算是一种CAS（Compare And Swep）操作，
  4 商品库存场景中number起到了版本控制（相当于version）的作用（ AND number=#{number}）。
  5 
  6 悲观锁之所以是悲观，在于他认为本次操作会发生并发冲突，所以一开始就对商品加上锁（SELECT … FOR UPDATE），
  7 然后就可以安心的做判断和更新，因为这时候不会有别人更新这条商品库存。
  8 
  9 从中我们也可以知道只要更新数据是依赖读取的数据作为基础条件的，就会有并发更新问题，需要乐观锁或者悲观锁取解决，
 10 特别实在计数表现明显。又比如在更新数据不依赖查询的数据的就不会有问题，
 11 例如修改用户的名称，多人同时修改，结果并不依赖于之前的用户名字，这就不会有并发更新问题。
 12 
 13 
 14 ================================
 15 1. 悲观锁
 16 
 17 顾名思义就是很悲观，每次拿数据都会认为别的线程会修改该数据，所以会给数据上锁；
 18 
 19 这样抢到锁的线程运行，取到数据做操作，
 20 
 21 这期间其他线程想要访问该数据时，都是阻塞block挂起状态，操作不了；
 22 
 23 核心就是不支持多并发，是单线程操作，通过抢占时间片的方式来抢锁的使用权，把并发变成了串行。
 24 
 25 共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。
 26 应用场景：
 27 
 28 悲观锁适用于多写的场景，保证线程安全和数据安全
 29 
 30 mysql的行锁、表锁、读锁、写锁；
 31 
 32 java中的synchronized。
 33 
 34 =================================
 35 2. 乐观锁
 36 
 37 顾名思义就是很乐观，每次拿数据都认为别的线程不会修改数据，因此不会给数据上锁；
 38 
 39 但会在数据更新时判断一下，在此期间其他线程有没有对该数据做更新，最终通过多个线程的逐一更新获取数据的最终值；
 40 应用场景：
 41 
 42 乐观锁适用于多读的场景，获取数据不再创建、销毁锁，减少了锁的开销，加大了数据的吞吐量，
 43 
 44 Redis等非关系型数据库
 45 
 46 ps：Redis是单线程操作，把事务封闭在单一线程中，避免了线程的安全问题，所以里面没有加悲观锁；
 47 
 48        不过对于依赖多个Redis操作的复合操作来说，还是需要加锁的，而且有可能是分布式锁，也可以用LUA脚本，用任务队列的方式解决多任务并发的问题。
 49 
 50  
 51 
 52 
 53 ========================SQlserver上的悲观锁解决方案==============================
 54 https://blog.csdn.net/gudenren/article/details/4397291
 55 
 56 ===》》》悲观锁定解决方案
 57 
 58 declare @CardNo varchar(20)
 59 Begin Tran
 60 
 61 -- 选择一张未使用的卡
 62 select top 1 @CardNo=F_CardNo
 63 from Card with (UPDLOCK) where F_Flag=0 //---F_Flag=0表示没有被人注册使用这张卡
 64 
 65 -- 延迟50秒，模拟并发访问.
 66 waitfor delay ‘000:00:50‘
 67 
 68 -- 把刚才选择出来的卡进行注册.
 69 
 70 update Card
 71 set F_Name=user,
 72 F_Time=getdate(),
 73 F_Flag=1
 74 where F_CardNo=@CardNo
 75 
 76 commit
 77 
 78 注重其中的区别了吗?with(updlock),是的,我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候
 79 我们就对记录加上了更新锁,表示我们即将对次记录进行更新.注重更新锁和共享锁是不冲突的,也就是其他用户还可以
 80 查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.假如我们在另外一个窗口执行此代码,
 81 同样不加waifor delay子句.两边执行完毕后,我们发现成功的注册了两张卡.
 82 可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候,其他更新用户必须排队等待,即使那个用户更新的不是同一条记录.
 83 
 84  
 85 
 86 
 87 ======》》》乐观锁
 88 乐观锁定解决方案
 89 
 90 -- 首先我们在Card表里边加上一列F_TimeStamp 列,该列是varbinary(8)类型.但是在更新的时候这个值会自动增长.
 91 
 92 alter table Card add F_TimeStamp timestamp not null
 93 
 94 -- 悲观锁定
 95 declare @CardNo varchar(20)
 96 declare @timestamp varbinary(8)
 97 declare @rowcount int
 98 
 99 Begin Tran
100 
101 -- 取得卡号和原始的时间戳值
102 select top 1 @CardNo=F_CardNo,
103 @timestamp=F_TimeStamp
104 from Card
105 where F_Flag=0
106 
107 -- 延迟50秒，模拟并发访问.
108 waitfor delay ‘000:00:50‘
109 
110 -- 注册卡,但是要比较时间戳是否发生了变化.假如没有发生变化.更新成功.假如发生变化,更新失败.
111 
112 update Card
113 set F_Name=user,
114 F_Time=getdate(),
115 F_Flag=1
116 where F_CardNo=@CardNo and F_TimeStamp=@timestamp
117 set @rowcount=@@rowcount
118 if @rowcount=1
119 begin
120 print ‘更新成功!‘
121 commit
122 end
123 else if @rowcount=0
124 begin
125 if exists(select 1 from Card where F_CardNo=@CardNo)
126 begin
127 print ‘此卡已经被另外一个用户注册！‘
128 rollback tran
129 end
130 else
131 begin
132 print ‘并不存在此卡!‘
133 rollback tran
134 end
135 end
136 
137 在另外一个窗口里边执行没有waitfor的代码,注册成功后,返回原来的窗口,我们就会发现到时间后它显示的提示是此卡以
138 被另外一个用户注册的提示.很明显,这样我们也可以避免两个用户同时注册一张卡的现象的出现.同时,
139 使用这种方法的另外一个好处是没有使用更新锁,这样增加的系统的并发处理能力.
140 
141 总结：上边我具体介绍了乐观锁定和悲观锁定的使用方法,在实际生产环境里边,假如并发量不大,
142 我们完全可以使用悲观锁定的方法,因为这种方法使用起来非常方便和简单.但是假如系统的并发非常大的话,
143 悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.