数据库锁机制的探讨

封锁（locking）

    所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制。

基本的封锁类型有两种：排他锁（Exclusive Locks，简称X锁）和共享锁（Share Locks，简称S锁）。

排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。

共享锁又称读锁。若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能在对A加S锁，而不能加X锁，直到T释放A上的S锁。

排它锁与共享锁的控制方式可以用如下图的相容矩阵表示。

T1

T2

X

S

-

X

N

N

Y

S

N

Y

Y

-

Y

Y

Y

Y=Yes,相容的请求

N=No，不相容的请求

三级封锁协议

在运用X锁和S锁对数据对象加锁时，还需要约定一些规则 ，例如何时申请X锁或S锁、持锁时间、何时释放等。称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。 

　　 

　　一、一级封锁协议  

　　 一级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。 

　　 一级封锁协议可以防止丢失更新，并保证事务T是可恢复的。使用一级封锁协议可以解决丢失更新问题。 

　　 在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，它不能保证可重复读和不读“脏”数据。  

　　二、二级封锁协议 　 

　　 二级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后立即释放S锁。 

　　 

　　 二级封锁协议除防止了丢失更新，还可以进一步防止读“脏”数据。但在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。 

　　 

　　三、三级封锁协议 

　　 三级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。 

　　 三级封锁协议除防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。

上述三级协议的主要区别在于什么操作需要申请什么封锁，以及何时释放锁。三个级别的封锁协议可以总结为下表：

不同级别的封锁协议

X锁

S锁

一致性保证

操作结束     释放

事务结束释放

操作结束释放

事务结束释放

不丢失更新

不读“脏”数据

可重复读

一级封锁协议

√

√

二级封锁协议

√

√

√

√

三级封锁协议

√

√

√

√

√

在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:

　　◆未授权读取(Read Uncommitted)：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

　　◆授权读取(Read Committed)：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

　　◆可重复读取(Repeatable Read)：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务)，写事务则禁止任何其他事务。

　　◆序列化(Serializable)：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

　　隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

活锁和死锁

一、活锁

如果事务T1封锁了数据R，事务T2有请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4有请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求......T2有可能永远等待，这就是活锁的情形。

避免活锁的简单方法是采用先来先服务的策略。

二、死锁

如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1有请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2有申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。

目前在数据库中解决死锁问题主要有两类方法：一是采取一定措施来预防死锁的发生；二是允许发生死锁，采用一定的手段定期诊断系统中有无死锁，若有则解除之。

1.死锁的预防

预防死锁有两种方法：

（1）一次封锁法

 一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。一次封锁法虽然能有效预防死锁，但也存在问题。第一，一次就将以后用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。第二，数据库中的数据是不断变化的，原来不要求封锁的数据，在执行过程中可能会变成封锁对象，所以很难事先精确地确定每个事务所要封锁的数据对象，为此只能扩大封锁范围，将事务在执行过程中可能要用到的数据对象全部加锁，这就进一步降低了并发度。

（2）顺序封锁法

 顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。

顺序封锁法可以有效的预防死锁，但也同样存在问题。第一，数据库系统中封锁的数据对象极多，并且随数据的插入、删除等操作而不断地变化，要维护这样的资源的封锁顺序非常困难，成本很高。第二，事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。

2.死锁的诊断与解除

（1）超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因是等待时间超过了时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。

（2）等待图法

事务等待图是一个有向图。T为结点的集合，每个节点表示正运行的事务；u为边的集合，每条边表示事务等待的情况。若T1等待T2，则T1，T2之间划一条有向边，从T1指向T2。事务等待图动态的反映了所有事务的等待情况。并发控制子系统周期性地检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。

DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有的所有的锁，使其他事务得以继续运行下去。当然，对撤销的事务所执行的数据修改操作必须加以恢复。

并发调度的可串行性

多个事务的并发执行是正确的，并且仅当其结果与按某一次序串行地执行它们时的结果相同，我们称这种调度策略为可串行化（Serializable）的调度。

可串行化是并发事务正确定的准则。目前DBMS普遍采用封锁方法实现并发操作调度的可串行性。

两段锁（Two-Phase Locking，简称2PL）协议就是保证并发调度可串行性的封锁协议。

两段锁协议

所谓两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁。

在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁；

在释放一个封锁之后，事务不在申请和获得任何其他封锁。

所谓“两段”锁的含义是，事务分两个阶段，第一阶段是获得封锁，也称为扩展阶段。在这阶段，事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁。第二阶段是释放封锁，也称为收缩阶段。在这阶段，事务可以释放任何数据项上的任何类型的锁，但是不能在申请任何锁。

封锁的粒度

封锁对象的大小成为封锁粒度（Granularity）。

封锁粒度与系统的并发度和并发控制的开销密切相关。封锁粒度越大并发度就越小，系统开销也越小；反之，封锁的粒度越小，并发度较高，但系统开销也就越大。

如果一个系统中同时支持多种封锁粒度供不同事务选择，这种封锁方法称为多粒度封锁（Multiple Granularity Locking）。

在多粒度封锁中一个数据对象可能以两种方式封锁，显示封锁和隐式封锁。显示封锁是应事务的要求直接加到数据对象上的封锁；隐式封锁是该数据对象没有独立加锁，由于其上级结点加锁而使该数据对象加上了锁。

一般地，对某个数据对象加锁，系统要检查该数据对象上有无显式封锁与之冲突；还要检查其所有上级结点，看本事务的显式封锁是否与该数据对象上的隐式封锁（即由于上级结点已加的封锁造成的）冲突；还要检查所有下级结点，看上面的显式封锁是否与本事务的隐式封锁（将加到下级结点的封锁）冲突。显然，这样的方法效率很低。为此引进了一种新型锁，称为意向锁（Intention Lock）。

意向锁

意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。

三种常用的意向锁：意向共享锁（Intent Share Lock,简称IS锁）;意向排它锁（Intent Exclusive Lock,简称IX锁）；共享意向排它锁（Share Intent Exclusive Lock，简称SIX锁）。

1.IS锁

如果对一个数据对象加IS锁，表示它的后裔结点拟（意向）加S锁。例如，要对某个元组加S锁，则要首先对关系和数据库加IS锁。

2.IX锁

如果对一个数据对象加IX锁，表示它的后裔结点拟（意向）加X锁。例如，要对某个元组加X锁，则要首先对关系和数据库加IX锁。

3.SIX锁

如果对一个数据对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。例如对某个表加SIX锁，则表示该事务要读整个表（所以要对该表加S锁），同时会更新个别元组（所以要对该表加IX锁）。

图（a）给出了这些锁的相容矩阵。

具有意向锁的多粒度封锁方法中任意事务T要对一个数据对象加锁，必须先对它的上层结点加意向锁。申请封锁时应该按自上而下的次序进行；释放封锁时则应该按自下而上的次序进行。

具有意向锁的锁粒度封锁方法提高了系统的并发度，减少了加锁和解锁的开销。

数据锁的相容矩阵

T1

T2

S

X

IS

IX

SIX

-

S

Y

N

Y

N

N

Y

X

N

N

N

N

N

Y

IS

Y

N

Y

Y

Y

Y

IX

N

N

Y

Y

N

Y

SIX

N

N

Y

N

N

Y

-

Y

Y

Y

Y

Y

Y

Y=Yes,表示相容的请求  N=No，表示不相容的请求

Latch（锁存器）

Latch是一种轻量级锁资源，它用于快速，短时间的锁定资源，防止多个并发进程同时修改访问某个共享资源，它只工作在内存中，我们可以不太准确的说，内存中资源的锁叫latch，数据库对象（表，索引等）的锁叫lock。比如数据缓存中的某个块（block）要被读取，我们会获得这个块的latch。这个过程叫做pin，另外一个进程恰好要修改这个块，也也要pin这个块，此时他必须等待，当前一个进程释放latch后才能pin住，然后修改，如果多个进程同时请求的话，他们之前将出现竞争，没有一个入队机制，一旦前面进程释放latch，后面的进程就蜂拥而上，没有先来后到的概念，这个和lock是有本质区别的，这一却都发生的非常快，因为latch的特点是快而短暂。

Latch和Lock的区别

1.Latch是对内存对象数据结构提供互斥访问的一种机制，而Lock是以不同的模式来套取共享资源对象，各个模式间存在着兼容或排斥，从这点看出，Latch的访问，包括查询也是互斥的，任何时候，只能有一个进程能pin住内存的某一块，幸好这个过程是相当的短暂，否则系统性能将没的保障。

2. Latch只作用于内存中，他只能被当前进程访问，而L ock作用于数据库对象，被当前事务拥有。

3. Latch是瞬间的占用，释放，Lock的释放需要等到事务正确的结束，他占用的时间长短由事务大小决定。

4. Latch是非入队的，而Lock是入队的。

5. Latch不存在死锁，而Lock中存在。