标签:data highlight 访问 nbsp 更新 需要 两种 排它锁 更改
总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此不会上锁,但是在更新时会判断其他线程在这之前有没有对数据进行修改,一般会使用版本号机制或CAS操作实现。
例如:
有这样一个表:
每次更新时update在条件后再附加一个时间为条件:
update user_info set password=‘somelog‘ where username=‘somelog‘ and time=‘2018-07-11‘;
因为如果并发操作,同一刻查询的时间一样,但是先插入时将时间更改,那么后更新的操作就不能进行,因为time的值被前一个操作更改了。
这就是乐观锁的实现原理,更新时附加一个版本号。
总是假设最坏的情况,每次取数据时都认为其他线程会修改,所以都会加锁(读锁、写锁、行锁等),当其他线程想要访问数据时,都需要阻塞挂起。可以依靠数据库实现,如行锁、读锁和写锁等,都是在操作之前加锁,在Java中,synchronized的思想也是悲观锁。
注:要使用数据库的悲观锁,我们必须关闭mysql数据库的自动提交属性,因为MySQL默认使用autocommit模式,也就是说,当你执行一个更新操作后,MySQL会立刻将结果进行提交。
悲观锁分为两种:共享锁和排它锁
共享锁是其它事务可以读但是不能写
排他锁是只有自己得事务有权限对此数据进行读写
SQL写法
共享锁(S):
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE;
排他锁(X):
SELECT * FROM table_name WHERE ... FOR UPDATE;
加锁必须先开启事务:begin;(开启事务)->加锁、操作->commit;(提交事务,归还锁)
加锁分为显式加锁与隐式加锁,上面的写法是显式加锁。mysql在执行insert、update会自动加锁,mysql对select却不会加锁。
例如:
不加锁
select * from data where username=‘somelog’;
加排它锁:
select * from data where username=‘somelog’ for update;
如果一个事务加了排它锁之后,另外一个事务不加锁的select也可以查询到数据
以上可以看出,锁不是针对事务的,排它锁只有一把,谁拿了谁就可以进行更新,但是没有拿到锁的事务只要在select不加上排它锁也可以查询到数据。
标签:data highlight 访问 nbsp 更新 需要 两种 排它锁 更改
原文地址:https://www.cnblogs.com/somelog/p/9295266.html