锁机制详解程序员

oracle数据库有两种锁策略，分别为悲观锁和乐观锁：

一.悲观锁
当用户想要修改一条数据时，根据键盘上的输入的数据，应用将提供绑定变量的值，然后重新利用这些绑定的变量的值作为过滤条件去查询这一行，这一次会锁定这一行，不允许其他会话更新。
在试图更新前就把记录锁住了，我们很悲观，对于这一行能不能保持未改变很是怀疑。

注意：
 

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

阻塞
定义：
当一个会话保持另一个会话正在请求的资源上的锁定时，就会发生阻塞。被阻塞的会话将一直挂起，直到持有锁的会话放弃锁定的资源为止。4个常见的dml语句会产生阻塞
INSERT
UPDATE
DELETE
SELECT…FOR UPDATE

INSERT
Insert发生阻塞的唯一情况就是用户拥有一个建有主键约束的表。当2个的会话同时试图向表中插入相同的数据时，其中的一个会话将被阻塞，直到另外一个会话提交或会滚。一个会话提交时，另一个会话将收到主键重复的错误。回滚时，被阻塞的会话将继续执行。
UPDATE 和DELETE当执行Update和delete操作的数据行已经被另外的会话锁定时，将会发生阻塞，直到另一个会话提交或会滚。
Select …for update
当一个用户发出select..for update的错作准备对返回的结果集进行修改时，如果结果集已经被另一个会话锁定，就是发生阻塞。需要等另一个会话结束之后才可继续执行。可以通过发出 select… for update nowait的语句来避免发生阻塞，如果资源已经被另一个会话锁定，则会返回以下错误：Ora-00054:resource busy and acquire with nowait specified. 

死锁-deadlock
定义:当两个用户希望持有对方的资源时就会发生死锁.
即两个用户互相等待对方释放资源时,oracle认定为产生了死锁,在这种情况下,将以牺牲一个用户作为代价,另一个用户继续执行,牺牲的用户的事务将回滚.
例子：
1：用户1对A表进行Update，没有提交。
2：用户2对B表进行Update，没有提交。
此时双反不存在资源共享的问题。
3：如果用户2此时对A表作update,则会发生阻塞，需要等到用户一的事物结束。
4：如果此时用户1又对B表作update，则产生死锁。此时Oracle会选择其中一个用户进行会滚，使另一个用户继续执行操作。
起因:
Oracle的死锁问题实际上很少见，如果发生，基本上都是不正确的程序设计造成的，经过调整后，基本上都会避免死锁的发生。

DML锁分类表

Oracle　RDBMS的封锁类型可分为如下三类:
1、内部锁和闩
　　内部级封锁是用于保护ORACLE内部结构，由系统内部实现，用户不能访问。
2、DDL锁

TM锁（表级锁）类型共有5种，分别称为共享锁（S锁）、排它锁（X锁）、行级共享锁（RS锁）、行级排它锁（RX锁）、共享行级排它锁（SRX锁）

当Oracle执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的SQL操作产生不同类型的TM锁。如表1所示。

TX锁等待的分析

Oracle数据库中一般使用行级锁。

当Oracle检测到死锁产生时，中断并回滚死锁相关语句的执行，报ORA-00060的错误并记录在数据库的日志文件alertSID.log中。同时在user_dump_dest下产生了一个跟踪文件，详细描述死锁的相关信息。

在日常工作中，如果发现在日志文件中记录了ora-00060的错误信息，则表明产生了死锁。这时需要找到对应的跟踪文件，根据跟踪文件的信息定位产生的原因。

解锁及Kill Session:

使用下面的语法查出锁并杀掉Session。

SELECT A.SID,A.SERIAL#,A.USERNAME,B.TYPE FROM V$SESSION A,V$LOCK B WHERE A.SID=B.SID;

ALTER SYSTEM KILL SESSION ‘SID,SERIAL#’;

3、DML锁
　　DML级封锁用于控制并发事务中的数据操纵，保证数据的一致性和完整性，其封锁对象可以是表或行。
　　对用户的数据操纵，Oracle可以自动为操纵的数据进行封锁，但如果有操纵授权，则为满足并发操纵的需要另外实施封锁。DML封锁可由一个用户进程以显式的方式加锁，也可通过某些SQL语句隐含方式实现。
　　DML锁有如下三种封锁方式:
　　(1)、共享封锁方式(SHARE)
　　(2)、独占封锁方式(EXCLUSIVE)
　　(3)、共享更新封锁(SHARE UPDATE)
　　其中SHARE，EXCLUSIVE用于表封锁，SHARE UPDATE用于行封锁。
　　1、共享方式的表封锁
　　共享方式的表封锁是对表中的所有数据进行封锁，该锁用于保护查询数据的一致性，防止其它用户对已封锁的表进行更更新。其它用户只能对该表再施加共享方式的锁，而不能再对该表施加独占方式的封锁，共享更新锁可以再施加，但不允许持有共享更新封锁的进程做更新。共享该表的所有用户只能查询表中的数据，但不能更新。共享方式的表封锁只能由用户用SQL语句来设置，基语句格式如下:
　　LOCK TABLE <表名>[,<表名>]…
　　IN SHARE MODE [NOWAIT]
　　执行该语句，对一个或多个表施加共享方式的表封锁。当指定了选择项NOWAIT，若该封锁暂时不能施加成功，则返回并由用户决定是进行等待，还是先去执行别的语句。
　　持有共享锁的事务，在出现如下之一的条件时，便释放其共享锁:
　　A、执行COMMIT或ROLLBACK语句。
　　B、退出数据库(LOG　OFF)。
　　C、程序停止运行。
　　共享方式表封锁常用于一致性查询过程，即在查询数据期间表中的数据不发生改变。
　　2、独占方式表封锁
　　独占方式表封锁是用于封锁表中的所有数据，拥有该独占方式表封锁的用户，即可以查询该表，又可以更新该表，其它的用户不能再对该表施加任何封锁(包括共享、独占或共享更新封锁)。其它用户虽然不能更新该表，但可以查询该表。
　　独占方式的表封锁可通过如下的SQL语句来显示地获得:
　　LOCK TABLE <表名>[,<表名>]….
　　IN EXCLUSIVE MODE [NOWAIT]
　　独占方式的表封锁也可以在用户执行DML语句INSERT、UPDATE、DELETE时隐含获得。
　　拥有独占方式表封锁的事务，在出现如下条件之一时，便释放该封锁:
　　(1)、执行COMMIT或ROLLBACK语句。
　　(2)、退出数据库(LOG OFF)
　　(3)、程序停止运行。
　　独占方式封锁通常用于更新数据，当某个更新事务涉及多个表时，可减少发生死锁。
　　3、共享更新封锁方式
　　共享更新封锁是对一个表的一行或多行进行封锁，因而也称作行级封锁。表级封锁虽然保证了数据的一致性，但却减弱了操作数据的并行性。行级封锁确保在用户取得被更新的行到该行进行更新这段时间内不被其它用户所修改。因而行级锁即可保证数据的一致性又能提高数据操作的迸发性。
　　可通过如下的两种方式来获得行级封锁:
　　(1)、执行如下的SQL封锁语句，以显示的方式获得:
　　LOCK TABLE <表名>[,<表名>]….
　　IN SHARE UPDATE　MODE [NOWAIT]
　　(2)、用如下的SELECT …FOR UPDATE语句获得:
　　SELECT <列名>[,<列名>]…
　　FROM <表名>
　　WHERE <条件>
　　FOR UPDATE OF <列名>[,<列名>]…..[NOWAIT]
　　一旦用户对某个行施加了行级封锁，则该用户可以查询也可以更新被封锁的数据行，其它用户只能查询但不能更新被封锁的数据行.如果其它用户想更新该表中的数据行，则也必须对该表施加行级锁.即使多个用户对一个表均使用了共享更新，但也不允许两个事务同时对一个表进行更新，真正对表进行更新时，是以独占方式封锁表，一直到提交或复原该事务为止。行锁永远是独占方式锁。
　　当出现如下之一的条件，便释放共享更新锁:
　　(1)、执行提交(COMMIT)语句;
　　(2)、退出数据库(LOG　OFF)
　　(3)、程序停止运行。
　　执行ROLLBACK操作不能释放行锁。
　　从上面讲述可见，ORACLE　RDBMS的加锁机制，解决了并发事务的相容与互斥问题。相容保证事务的并发性，互斥确保数据的一致性。不同用户锁的相容与互斥关系由下图给出。
　　其中最后一行最后一列为其它用户提供在不同行上设置SHARE UPDATE锁。但当用户1在某行上进行更新操作时，用户2只有等待用户1提交事务后，才能更新自己所封锁的行。
　　中最后一行最后一列为其它用户提供在不同行上设置SHARE UPDATE锁。但当用户1在某行上进行更新操作时，用户2只有等待用户1提交事务后，才能更新自己所封锁的行。