mysql锁2

死锁:

指两个事务或者多个事务在同一资源上相互占用,并请求对方所占用的资源,从而造成恶性循环的现象。 

出现死锁的原因: 

系统资源不足; 
进程运行推进的顺序不当; 
资源分配不当。 

产生死锁的四个必要条件: 
互斥条件: 一个资源只能被一个进程使用;
请求和保持条件:进行获得一定资源,又对其他资源发起了请求,但是其他资源被其他线程占用,请求阻塞,但是也不会释放自己占用的资源;
不可剥夺条件: 指进程所获得的资源,不可能被其他进程剥夺,只能自己释放;
环路等待条件: 进程发生死锁,必然存在着进程-资源之间的环形链。

数据库也会发生死锁的现象,数据库系统实现了各种死锁检测和死锁超时机制来解除死锁,锁监视器进行死锁检测,MySQL的InnoDB处理死锁的方式是将持有最少行级排它锁的事务进行回滚。

常见的三种避免死锁的方法:

如果不同程序会并发存取多个表,尽量约定以相同的顺序访问表,可以大大降低死锁机会;

在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁产生概率;

对于非常容易产生死锁的业务部分,可以尝试使用升级锁定颗粒度,通过表级锁定来减少死锁产生的概率。

乐观锁和悲观锁都是为了解决并发控制问题, 乐观锁可以认为是一种在最后提交的时候检测冲突的手段,而悲观锁则是一种避免冲突的手段。 

乐观锁:

乐观锁应用系统层面和数据的业务逻辑层次上的(实际上并没有加锁,只不过大家一直这样叫而已),利用程序处理并发, 它假定当某一个用户去读取某一个数据的时候,其他的用户不会来访问修改这个数据,但是在最后进行事务的提交的时候会进行版本的检查,以判断在该用户的操作过程中,没有其他用户修改了这个数据。

乐观锁不是数据库自带的,需要我们自己去实现。乐观锁的实现大部分都是基于版本控制实现的,级别高低是:脏读 < 不可重复读 < 幻读(级别介绍详细见数据库的事务隔离级别)。 除此之外,还可以通过时间戳的方式,通过提前读取,事后对比的方式实现。

悲观锁:

每次拿数据的时候都认为别的线程会修改数据,所以在每次拿的时候都会给数据上锁。上锁之后,当别的线程想要拿数据时,就会阻塞,直到给数据上锁的线程将事务提交或者回滚。传统的关系型数据库里就用到了很多这种锁机制,比如行锁,表锁,共享锁,排他锁等,都是在做操作之前先上锁。与乐观锁相对应的,悲观锁是由数据库自己实现,要用的时候,我们直接调用数据库的相关语句就可以。

共享锁和排它锁是悲观锁的不同的实现,它俩都属于悲观锁的范畴。

共享锁:

共享锁又称为读锁,简称S锁,共享锁就是多个事务对于同一数据可以共享一把锁,都能访问到数据,但是只能读不能修改。

比如事务T对数据对象A加上S锁,则事务T只能读A;其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁。这就保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。

排他锁:

排他锁又称为写锁,简称X锁,排他锁就是不能与其他所并存,如一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的其他锁,包括共享锁和排他锁,但是获取排他锁的事务是可以对数据就行读取和修改。

比如事物T对数据对象A加上X锁,则只允许T读取和修改A,其它任何事务都不能再对A加任何类型的锁,直到T释放A上的锁。它防止任何其它事务获取资源上的锁,直到在事务的末尾将资源上的原始锁释放为止。

注意:

mysql InnoDB引擎默认的修改数据语句,update,delete,insert都会自动给涉及到的数据加上排他锁,select语句默认不会加任何锁类型,如果加排他锁可以使用select ...for update语句,加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的,也不能通过for update和lock in share mode锁的方式查询数据,但可以直接通过select ...from...查询数据,因为普通查询没有任何锁机制。
---------------------
作者:一骑走烟尘
来源:CSDN
原文:https://blog.csdn.net/zgcr654321/article/details/82345087
版权声明:本文为博主原创文章,转载请附上博文链接!

posted @ 2019-03-14 23:35  御世制人  阅读(208)  评论(0编辑  收藏  举报