数据库锁

锁

锁是数据库中的一个非常重要的概念，当多个用户同时对数据库并发操作时，会带来数据不一致的问题，所以，锁主要用于多用户环境下保证数据库完整性和一致性

数据库锁作用：处理并发带来的问题

并发控制的主要采用的技术手段：乐观锁、悲观锁和时间戳

锁的分类

数据库系统角度：排他锁、共享锁、更新锁

程序员角度：悲观锁、乐观锁

悲观锁（Pessimistic Lock）

它很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人拿这个数据就会block（阻塞），直到它结束

悲观锁，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

传统的关系数据库里用到了很多这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁。

悲观锁按使用性质划分：共享锁（Share Lock）、排他锁（Exclusive Lock）、更新锁

共享锁（Share Lock）

S锁，也叫读锁，用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。 

特点：
      1. 多个事务可封锁同一个共享页
      2. 任何事务都不能修改该页
      3. 通常是该页被读取完毕，S锁立即被释放

在SQL Server中，默认情况下，数据被读取后，立即释放共享锁 
       “SELECT * FROM my_table”：首先锁定第一页，读取之后，释放对第一页的锁定，然后锁定第二页。这样，就允许在读操作过程中，修改未被锁定的第一页。 
       “SELECT * FROM my_table HOLDLOCK”：就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。

排他锁（Exclusive Lock）

X锁，也叫写锁，表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了。
特点：
       1. 仅允许一个事务封锁此页 
       2. 其他任何事务必须等到X锁被释放才能对该页进行访问 
       3. X锁一直到事务结束才能被释放

产生排他锁的SQL语句如下：select * from ad_plan for update;

更新锁

U锁，在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象

因为当使用共享锁时，修改数据的操作分为两步： 
       1. 首先获得一个共享锁，读取数据， 
       2. 然后将共享锁升级为排他锁，再执行修改操作。 
       这样如果有两个或多个事务同时对一个事务申请了共享锁，在修改数据时，这些事务都要将共享锁升级为排他锁。这时，这些事务都不会释放共享锁，而是一直等待对方释放，这样就造成了死锁。 如果一个数据在修改前直接申请更新锁，在数据修改时再升级为排他锁，就可以避免死锁。

特点：
       1. 用来预定要对此页施加X锁，它允许其他事务读，但不允许再施加U锁或X锁； 
        2. 当被读取的页要被更新时，则升级为X锁； 
        3. U锁一直到事务结束时才能被释放。

悲观锁按作用范围划分为：行锁、表锁

行锁：行级别

表锁：整张表

数据库能够确定哪些行需要锁的情况下使用行锁，如果不知道会影响哪些行的时候就会使用表锁

如：一个用户表user，有主键id和用户生日birthday
       update … where id=?：行锁
       update … where birthday=?：表锁
 

乐观锁（Optimistic Lock）

它很乐观，每次去拿数据的时候都认为别人不会修改，所以，不会上锁。但是在更新的时候会判断一下在此期间别人有没有更新这个数据，可以使用版本号等机制

       乐观锁（ Optimistic Locking ）： 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。 悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。 

       乐观锁，大多是基于数据版本（ Version ）记录机制实现。

       乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁

乐观锁的实现方式：

1、版本号（version）

       给数据增加一个版本标识，在数据库上就是表中增加一个version字段，每次更新把这个字段加1，读取数据的时候把version读出来，更新的时候比较version，如果还是开始读取的version就可以更新了，如果现在的version比老的version大，说明有其他事务更新了该数据，并增加了版本号，这时候得到一个无法更新的通知，用户自行根据这个通知来决定怎么处理，比如重新开始一遍。这里的关键是判断version和更新两个动作需要作为一个原子单元执行，否则在你判断可以更新以后正式更新之前有别的事务修改了version，这个时候你再去更新就可能会覆盖前一个事务做的更新，造成第二类丢失更新，所以你可以使用update … where … and version=”old version”这样的语句，根据返回结果是0还是非0来得到通知，如果是0说明更新没有成功，因为version被改了，如果返回非0说明更新成功

2、时间戳

和版本号基本一样，只是通过时间戳来判断而已，注意时间戳要使用数据库服务器的时间戳不能是业务系统的时间。

3、待更新字段

和版本号方式相似，只是不增加额外字段，直接使用有效数据字段做版本控制信息，因为有时候我们可能无法改变旧系统的数据库表结构。假设有个待更新字段叫count,先去读取这个count,更新的时候去比较数据库中count的值是不是我期望的值（即开始读的值），如果是就把我修改的count的值更新到该字段，否则更新失败。java的基本类型的原子类型对象如AtomicInteger就是这种思想

4、所有字段 

和待更新字段类似，只是使用所有字段做版本控制信息，只有所有字段都没变化才会执行更新

乐观锁多种实现方式的选择：

新系统设计可以使用version方式和timestamp方式，需要增加字段，应用范围是整条数据，不论那个字段修改都会更新version,也就是说两个事务更新同一条记录的两个不相关字段也是互斥的，不能同步进行。

旧系统不能修改数据库表结构的时候使用数据字段作为版本控制信息，不需要新增字段，待更新字段方式只要其他事务修改的字段和当前事务修改的字段没有重叠就可以同步进行，并发性更高

并发控制会造成两种锁

• 活锁
• 死锁

活锁 

指的是T1封锁了数据R，T2同时也请求封锁数据R，T3也请求封锁数据R，当T1释放了锁之后，T3会锁住R，T4也请求封锁R，则T2就会一直等待下去。 

解决方法：采用“先来先服务”策略可以避免。

死锁 

就是我等你，你又等我，双方就会一直等待下去。比如：T1封锁了数据R1，正请求对R2封锁，而T2封住了R2,正请求封锁R1，这样就会导致死锁，死锁这种没有完全解决的方法，只能尽量预防

死锁的四个必要条件

互斥条件（Mutual exclusion）：资源不能被共享，只能由一个进程使用。
       请求与保持条件（Hold and wait）：已经得到资源的进程可以再次申请新的资源。
       非剥夺条件（No pre-emption）：已经分配的资源不能从相应的进程中被强制地剥夺。
       循环等待条件（Circular wait）：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。

处理死锁的策略

      1.忽略该问题。例如鸵鸟算法，该算法可以应用在极少发生死锁的的情况下。为什么叫鸵鸟算法呢，因为传说中鸵鸟看到危险就把头埋在地底下，可能鸵鸟觉得看不到危险也就没危险了吧
      2.检测死锁并且恢复。
      3.仔细地对资源进行动态分配，以避免死锁。
      4.通过破除死锁四个必要条件之一，来防止死锁产生。

系统判定死锁的方法：

       超时法：如果某个事物的等待时间超过指定时限，则判定为出现死锁；
       等待图法：如果事务等待图中出现了回路，则判断出现了死锁。

       对于解决死锁的方法，只能是撤销一个处理死锁代价最小的事务，释放此事务持有的所有锁，同时对撤销的事务所执行的数据修改操作必须加以恢复