事物并发出现的问题,以及悲观锁和乐观锁得问题

事物并发出现的问题

a)        脏读(Dirty Read)、读到未提交的数据。

读了另外一个事务的没有提交的数据

b)        不可重复读(NonRepeatable Read)

在同一个事物里头,前后读了2次是不一样的。(可能存在读的过程中另一个事务修改了数据)

c)        幻读(Phantom Read)

在你读的过程中,另一个事务向里面插入了一个新数据,影响你读的结果。

插入和删除的操作(这里一般数据库的锁只管不许更新,删除和插入时可以的)

 

Java.sql.connection 里面有事务的隔离级别、hibernate也是一样的

a)      read-uncommitted : 能够读未提交的数据   3个都会出现

b)      read-committed: 你不能限制重复读

c)      repeateable read: 底层就是加锁的机制。

d)      Serializable: 不管多少个事务来,你给我一个一个的执行,还会有问题吗?肯定就没有了。

 

 

悲观锁、乐观锁机制

为了考虑并发的效率,我们把它设定为read committed,但是我需要解决的是不可重复读、在hibernate中有两种方式来解决

 

 

悲观锁

Accounta = (Account)session.load(Account.class, 1, LookMode. upgrade);//upgrade

Select* from …..for update

底层用到的是数据库锁得机制(只能我读完了后别的才能够更新)

 

乐观锁

Version的机制,它不加锁,用一个version字段。表的字段自己加,然后更新是hibernate更新的。

 

 

对应的表

隔离级别

脏读(Dirty Read)

不可重复读(NonRepeatable Read)

幻读(Phantom Read)

读未提交(Read uncommitted)

可能

可能

 可能

读已提交(Read committed)

不可能

可能

可能

可重复读(Repeatable read)

不可能

不可能

可能

可串行化(Serializable )

不可能

不可能

不可能

 






这个是不支持事务的情况下,会出现的问题。一般不需考虑






 


### MySQL 中乐观锁悲观锁的概念 #### 悲观锁 悲观锁假设数据冲突的可能性较大,在每次访问共享资源前都加锁,直到事务结束才释放。这种方式确保了同一时间只有一个线程能够修改数据,从而避免了并发问题。 在 MySQL 中,`SELECT ... FOR UPDATE` `LOCK IN SHARE MODE` 是典型的悲观锁实现方法[^4]。这些语句会在查询的数据集上加上排他锁或共享锁,防止其他事务对该部分数据进行更改直至当前事务完成。 ```sql -- 获取排他锁 SELECT * FROM table_name WHERE id = ? FOR UPDATE; ``` #### 乐观锁 乐观锁则假定多个事务不会同时尝试修改相同记录的概率较低,因此不主动锁定数据库中的任何对象;而是在提交更新时检查是否有其他事务已经改变了该条目。如果发现有变化,则拒绝执行本次更新操作,并可能抛出异常让应用程序处理重试逻辑。 对于 MySQL 来说,可以通过引入额外字段如版本号(`version`)来支持乐观锁机制。当某一行被读取出来准备做修改之前,连同其对应的版本号一起取出;之后在实际执行 update 的时候增加一个条件判断——只有当 version 字段值未变过的情况下才能允许此次更新生效,否则说明期间发生了竞争状况需回滚交易重新发起请求[^3]。 ```sql UPDATE table_name SET column1=value1, ..., version=version+1 WHERE id=? AND version=original_version_value; ``` ### 应用场景分析 - **高并发读环境下的选择** - 对于大多数情况下都是只读或者极少发生的写入操作而言,采用乐观锁能有效减少不必要的等待时间死锁风险,提高整体性能表现。 - **频繁写入场景的选择** - 如果业务模型涉及到大量的插入/删除动作以及短生命周期的事物处理流程,那么更倾向于选用悲观锁策略以保障数据一致性不受影响。 ### 技术细节补充 除了上述提到的方法外,还可以利用 Redis 或 Memcached 这样的缓存服务配合特定算法(比如 CAS)来间接达成类似的效果。不过值得注意的是,无论采取哪种形式的同步措施,都需要充分考虑到具体应用场景特点做出合理权衡[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值