乐观锁、悲观锁,设计,解决的问题,保证原子性

介绍

并发问题:多用户环境下,同一时间多个用户/线程更新同一组数据,会产生冲突。

悲观锁:很悲观,假定每一次用户操作数据都会对其修改,会产生并发冲突,所以每次操作数据都会上锁。强独占性,阻塞锁。
乐观锁:很乐观,假定每一次用户操作数据都不会对其修改,不会产生并发冲突,所以不会上锁,但是会用版本号等机制判断是否修改了。不能解决脏读

使用方法

悲观锁:很多数据库有多种锁机制,例如行锁,表锁等,读锁,写锁等。悲观锁就是利用数据库的这些锁机制,例如SQL语句中使用for update。
select * from good where id=”1231” for update.这样在事务提交前id为1231的记录外界无法修改
Synchronized属于悲观锁

乐观锁:使用版本号记录机制实现,一般是给表添加一列version数据,当读取数据时,将version字段的值一同读出,数据更新,对此version值加一。当提交更新的时候,判断更新后的数据版本号是否大于数据库记录的版本号,大于则更新(或者根据版本号判断之前获取和数据库的是否一致,根据where version= 的方式更新数据,并version+1)。或者使用时间戳字段,如果更新前看到之前获取的时间戳与当前数据库中记录的时间戳一致,则可以更新。
例如使用版本号,当然最好带上之前的状态:update good set status=“已发货”,version=version+1 where id=1321 and version=331 and status = “已支付”
使用CAS


悲观锁使用Synchronized,保证每次只有一个线程运行程序
CAS是乐观锁的一种实现方式,java.util.concurrent(J.U.C)是建立在CAS之上的。

使用场景

在实际生产环境里,如果并发量不大且不允许脏读,可以使用悲观锁解决并发问题;但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以尽量选择乐观锁定的方法.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值