【数据库层面的悲观锁,乐观锁】
【乐观锁】不是数据库自带的,需要我们自己去实现。乐观锁是指操作数据库时(更新操作),认为这次操作不会导致冲突,在操作数据时,不进行任何
其他的特殊处理,在进行更新后,再去判断是否有冲突。
通常实现是这样的:在表中数据进行操作时,先给数据表加一个版本字段,每操作一次,将那条记录的版本号加一。也就是先查询出那条记录,获取
version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚查出的version的值相等,如果相等,说明这段时间没有其他程序对其进行操作,
则可以执行更新,version的值加1;如果version的值不相等,说明这段时间已经有其他程序对其进行操作了,则不进行更新操作。
除了基于版本控制实现外,还可以通过时间戳的方式,通过提前读取,事后对比的方式实现
【悲观锁】悲观锁是由数据库自己实现了的,要用的时候,直接调用数据库相关语句就可以了
-----------------
【共享锁】(读锁):同一时间段内,多个用户可以读取同一个资源,读取的过程中数据不会发生任何变化。读锁之间是相互不阻塞的,多个用户可以同时读,但是
不允许有人修改,任何事务都不允许获得数据上的排他锁,直到数据上释放掉所有的共享锁。
在执行语句后加lock in share mode
【排他锁】(写锁):在任何时候只能有一个用户写入资源,当进行写锁时会阻塞其他的读锁或者写锁操作,只能由这一个用户来写,其他用户既不能读也不能写
指的是对于多个不同的事务,对同一个资源只能有一把锁。在执行语句后加上for update
··加锁会有粒度问题,从粒度上从大到小可以划分为
【表锁】获取锁定资源开销较小,一旦有用户访问这个表就会加锁,其他用户就不能对这个表操作了,应用程序的访问请求遇到锁等待的可能性比较高,并发处理能力弱
【行锁】获取锁定资源开销较大,能具体锁定到表中的某一行数据,但是能更好的支持并发处理,会发生死锁
【页锁】是mysql中比较独特的一种锁定级别,锁定粒度介于行锁和表锁之间,所以获取锁定的资源开销也介于二者之间,另外,页级锁定和行级锁定一样,会发生死锁
共享锁(share lock)
又称读锁,读取操作创建的锁。
一旦上锁,任何事务(包括当前事务)无法对其修改,其他事务可以并发读取数据,也可在对此数据再加共享锁
语法:SELECT ... LOCK IN SHARE MODE;
排他锁(exclusive lock)
又称写锁,如果事务对数据A加上排他锁后,则其他事务不可并发读取数据,也不能再对A加任何类型的锁。获准排他锁的事务既能读数据,又能修改数据。
语法:SELECT ... FOR UPDATE
意向锁
InnoDB所用的表级锁,其设计目的主要是为了在一个事务中揭示下一步将要被请求的锁的类型。
InnoDB中的两个表锁:
意向共享锁(IS):表示事务准备给数据行加入共享锁,也就是说一个数据行加共享锁前必须先取得该表的IS锁
意向排他锁(IX):类似上面,表示事务准备给数据行加入排他锁,说明事务在一个数据行加排他锁前必须先取得该表的IX锁。
意向锁是InnoDB自动加的,不需要用户干预。
IX,IS是表级锁,不会和行级的X,S锁发生冲突。只会和表级的X,S发生冲突。
意向锁是一种快速判断表锁与之前可能存在的行锁冲突的机制。
1.在mysql中有表锁
LOCK TABLE my_tabl_name READ; 用读锁锁表,会阻塞其他事务修改表数据。
LOCK TABLE my_table_name WRITe; 用写锁锁表,会阻塞其他事务读和写。
2.Innodb引擎又支持行锁,行锁分为
共享锁,一个事务对一行的共享只读锁。
排它锁,一个事务对一行的排他读写锁。
3.这两中类型的锁共存的问题考虑这个例子:
事务A锁住了表中的一行,让这一行只能读,不能写。
之后,事务B申请整个表的写锁。
如果事务B申请成功,那么理论上它就能修改表中的任意一行,这与A持有的行锁是冲突的。
数据库需要避免这种冲突,就是说要让B的申请被阻塞,直到A释放了行锁。
数据库要怎么判断这个冲突呢?
step1:判断表是否已被其他事务用表锁锁表
step2:判断表中的每一行是否已被行锁锁住。
注意step2,这样的判断方法效率实在不高,因为需要遍历整个表。于是就有了意向锁。
在意向锁存在的情况下,事务A必须先申请表的意向共享锁,成功后再申请一行的行锁。
在意向锁存在的情况下,上面的判断可以改成step1:不变
step2:发现表上有意向共享锁,说明表中有些行被共享行锁锁住了,因此,事务B申请表的写锁会被阻塞。
注意:申请意向锁的动作是数据库完成的,就是说,事务A申请一行的行锁的时候,数据库会自动先开始申请表的意向锁,不需要我们程序员使用代码来申请。