Select …forupdate语句是我们经常使用手工加锁语句。通常情况下，select语句是不会对数据加锁，妨碍影响其他的DML和DDL操作。同时，在多版本一致读机制的支持下，select语句也不会被其他类型语句所阻碍。
借助for update子句，我们可以在应用程序的层面手工实现数据加锁保护操作。本篇我们就来介绍一下这个子句的用法和功能。
下面是采自Oracle官方文档《SQLLanguage Reference》中关于for update子句的说明：(请双击点开图片查看)
从for update子句的语法状态图中，我们可以看出该子句分为两个部分：加锁范围子句和加锁行为子句。下面我们分别针对两个方面的进行介绍。
加锁范围子句
在select…for update之后，可以使用of子句选择对select的特定数据表进行加锁操作。默认情况下，不使用of子句表示在select所有的数据表中加锁。
//采用默认格式for update
SQL> select * from emp where rownum<2 for update;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
----- ---------- --------- ----- ----------- --------- --------- ------
7369 SMITH CLERK 79021980-12-17 800.00 20
此时，我们观察v$lock和v$locked_object视图，可以看到锁信息。
//事务信息视图
SQL> select addr,xidusn,xidslot,xidsqn from v$transaction;
ADDR XIDUSN XIDSLOT XIDSQN
-------- ---------- ---------- ----------
377DB5D0 7 19 808
//锁对象信息
SQL> select xidusn,xidslot,xidsqn,object_id,session_id, oracle_username from v$locked_object;
XIDUSN XIDSLOT XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAME
---------- ---------- ---------- ---------- ---------- ------------------------------
7 19 808 73181 36 SCOTT
//
SQL> select owner,object_name from dba_objects where object_id=73181;
OWNER OBJECT_NAME
------------------------------ ------------------------------------------------------------
SCOTT EMP
//
SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid=36;
ADDR SID TYPE ID1 ID2 LMODE REQUEST BLOCK
-------- ---------- ---- ---------- ---------- ---------- ---------- ----------
37E808F0 36 AE 100 0 4 0 0
B7DE8A44 36 TM 73181 0 3 0 0
377DB5D0 36 TX 458771 808 6 0 0
从上面的情况看，默认情况下的for update语句，效果相当于启动了一个会话级别的事务，在对应的数据表（select所涉及的所有数据表）上加入一个数据表级共享锁（TM，lmode=3）。同时，在对应的数据行中加入独占锁（TX，lmode=6）。
根据我们以前的知识，如果此时有另一个会话视图获取对应数据行的独占权限（无论是用update/delete还是另一个for update），都会以block而告终。
SQL> select sid from v$mystat where rownum<2;
SID
----------
37
SQL> select * from emp where empno=7369 for update;
//系统blocking
此时系统中状态，切换到另一个用户下进行观察：
SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid in (36,37);
ADDR SID TYPE ID1 ID2 LMODE REQUEST BLOCK
-------- ---------- ---- ---------- ---------- ---------- ---------- ----------
37E808F0 36 AE 100 0 4 0 0
37E80ED4 37 AE 100 0 4 0 0
37E80F48 37 TX 458771 808 0 6 0
B7DE8A44 37 TM 73181 0 3 0 0
B7DE8A44 36 TM 73181 0 3 0 0
377DB5D0 36 TX 458771 808 6 0 1
6 rows selected
SQL> select * from dba_waiters;
WAITING_SESSION HOLDING_SESSION LOCK_TYPE MODE_HELD MODE_REQUESTED LOCK_ID1 LOCK_ID2
--------------- --------------- -------------------------- ---------------------------------------- ---------------------------------------- ---------- ----------
37 36Transaction Exclusive Exclusive 458771 808
由此，我们可以获取到结论：for update子句的默认行为就是自动启动一个事务，借助事务的锁机制将数据进行锁定。
Of子句是配合for update语句使用的一个范围说明标记。从官方的语法结构看，后面可以跟一个或者多个数据列列表。这种语法场景常常使用在进行连接查询的select中，对其中一张数据表数据进行锁定。
SQL> select empno,ename,job,mgr,sal from emp,dept where emp.deptno=dept.deptno and empno=7369 for update of emp.empno;
EMPNO ENAME JOB MGR SAL
----- ---------- --------- ----- ---------
7369 SMITH CLERK 7902 800.00
SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid=36;
ADDR SID TYPE ID1 ID2 LMODE REQUEST BLOCK
-------- ---------- ---- ---------- ---------- ---------- ---------- ----------
37E808F0 36 AE 100 0 4 0 0
B7E1C2E8 36 TM 73181 0 3 0 0
377DBC0C 36 TX 65566 747 6 0 0
上面的语句中，我们看到使用for update of指定数据列之后，锁定的范围限制在了所在的数据表。也就是说，当我们使用连接查询配合of子句的时候，可以实现有针对性的锁定。
同样在连接查询的时候，如果没有of子句，同样采用默认的模式，会如何呢？
SQL> select empno,ename,job,mgr,sal from emp,dept where emp.deptno=dept.deptno and empno=7369 for update;
EMPNO ENAME JOB MGR SAL
----- ---------- --------- ----- ---------
7369 SMITH CLERK 7902 800.00
SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid=36;
ADDR SID TYPE ID1 ID2 LMODE REQUEST BLOCK
-------- ---------- ---- ---------- ---------- ---------- ---------- ----------
37E808F0 36 AE 100 0 4 0 0
B7E1C2E8 36 TM 73179 0 3 0 0
B7E1C2E8 36 TM 73181 0 3 0 0
377DBC0C 36 TX 458777 805 6 0 0
SQL> select owner,object_name from dba_objects where object_id=73179;
OWNER OBJECT_NAME
------------------------------ --------------------------------------------------------------------------------
SCOTT DEPT
明显可以看到，当我们没有使用of子句的时候，默认就是对所有select的数据表进行lock操作。
加锁行为子句
加锁行为子句相对比较容易理解。这里分别介绍。
Nowait子句
当我们进行for update的操作时，与普通select存在很大不同。一般select是不需要考虑数据是否被锁定，最多根据多版本一致读的特性读取之前的版本。加入for update之后，Oracle就要求启动一个新事务，尝试对数据进行加锁。如果当前已经被加锁，默认的行为必然是block等待。
使用nowait子句的作用就是避免进行等待，当发现请求加锁资源被锁定未释放的时候，直接报错返回。
///session1中
SQL> select * from emp for update;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
----- ---------- --------- ----- ----------- --------- --------- ------
7369 SMITH CLERK 79021980-12-17 800.00 20
7499 ALLEN SALESMAN 76981981-2-20 1600.00 300.00 30
7521 WARD SALESMAN 76981981-2-22 1250.00 500.00 30
7566 JONES MANAGER 78391981-4-2 2975.00 20
//变换session，进行执行。
SQL> select * from emp for update nowait;
select * from emp for update nowait
ORA-00054:资源正忙,但指定以NOWAIT方式获取资源,或者超时失效
对应的还有就是wait子句，也就是默认的for update行为。一旦发现对应资源被锁定，就等待blocking，直到资源被释放或者用户强制终止命令。
对wait子句还存在一个数据参数位，表示当出现blocking等待的时候最多等待多长时间。单位是秒级别。
//接上面的案例
SQL> select * from emp for update wait 3;
select * from emp for update wait 3
ORA-30006:资源已被占用;执行操作时出现WAIT超时
Skip locked参数
Skip locked参数是最新引入到for update语句中的一个参数。简单的说，就是在对数据行进行加锁操作时，如果发现数据行被锁定，就跳过处理。这样for update就只针对未加锁的数据行进行处理加锁。
//session1中，对一部分数据加锁；
SQL> select * from emp where rownum<4 for update;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
----- ---------- --------- ----- ----------- --------- --------- ------
7369 SMITH CLERK 79021980-12-17 800.00 20
7499 ALLEN SALESMAN 76981981-2-20 1600.00 300.00 30
7521 WARD SALESMAN 76981981-2-22 1250.00 500.00 30
//在session2中；
SQL> select * from emp for update skip locked;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
----- ---------- --------- ----- ----------- --------- --------- ------
（篇幅原因，省略）
7934 MILLER CLERK 77821982-1-23 1300.00 10
11 rows selected
总数据一共14行。Session1中，先lock住了3行数据。之后的seesion2中，由于使用的skip locked子句参数，将剩下的11条数据进行读取到并且加锁。
对for update的使用
在日常中，我们对for update的使用还是比较普遍的，特别是在如pl/sql developer中手工修改数据。此时只是觉得方便，而对for update真正的含义缺乏理解。
For update是Oracle提供的手工提高锁级别和范围的特例语句。Oracle的锁机制是目前各类型数据库锁机制中比较优秀的。所以，Oracle认为一般不需要用户和应用直接进行锁的控制和提升。甚至认为死锁这类锁相关问题的出现场景，大都与手工提升锁有关。所以，Oracle并不推荐使用for update作为日常开发使用。而且，在平时开发和运维中，使用了for update却忘记提交，会引起很多锁表故障。
那么，什么时候需要使用for update？就是那些需要业务层面数据独占时，可以考虑使用for update。场景上，比如火车票订票，在屏幕上显示邮票，而真正进行出票时，需要重新确定一下这个数据没有被其他客户端修改。所以，在这个确认过程中，可以使用for update。这是统一的解决方案方案问题，需要前期有所准备
Hibernate中的乐观锁和悲观锁
在了解Hibernate的LockMode之前，我们先讲一下LockMode是什么东西？其实LockMode只是在使用Hibernate 中 的session.load()加载数据时指定的模式，也叫悲观锁（模式），然而，悲观锁是为了弥补read-committed 机制的不足，从而解决non-repeatable （不可重复读）和 phantom-read （幻读）问题，而non-repeatable 和 phantom-read 这两个问题也只是事务并发 是产生的两种问题...看了我写的这一段后，我相信很多读者会有点懵，这就对了，看完下面的文章，再后过头来读这一段，就全都明白了。
我们知道，事务由那几个特性，四个（ACID）：
1.原子性(Atomicity）：
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
2.一致性（Consistency）
在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
3.隔离性（Isolation）
两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。
4.持久性（Durability）
在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
由于一项操作通常会包含许多子操作，而这些子操作可能会因为硬件的损坏或其他因素产生问题，要正确实现ACID并不容易。ACID建议数据库将所有需要更新以及修改的资料一次操作完毕，但实际上并不可行。
一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
在处理事务过程中，事务并发是不可避免的，从而会出现以下几个问题：
1.丢失更新（Lost Update）（第一类和第二类）
2.脏读（Dirty Read）
3.不可重复读（Non-repeatable Read）
4.幻读（Phantom Read）
针对并发事务出现的问题，Hibernate 采用了数据库的事务隔离机制（详细文档见Herbernate 参考文档的 java.sql.Connection ）,一般有以下四种处理机制：
1.read-uncommitted
2.read-committed
3.repeatable read
4.serializable
四种机制的具体价值：
A. 只要数据库支持事务，就不可能出现第一类丢失更新
B. read-uncommitted（允许读取未提交的数据）会出现dirty read , phantom-read,non-repeatable read 问题
C. read-committed（读取已提交的数据，项目中一般使用这个，MySql 数据库默认是这种机制）不会出现dirty read ，因为只有另一个事务提交才会读出来结果，但仍然会出现non-repeatable和phantom-read
（所以使用read-committed 机制可用悲观锁和乐观锁来解决non-repeatable 和 phantom-read 问题）
在hibernate中的事务隔离级别的设定（使用 hibernate.connection.isolation配置，取之1，2，4，8）
1.hibernate.connection.isolation = 2 （如果不设置，默认依赖数据库本身的级别，例如MySql为2，read-committed）
2.使用悲观锁解决repeatable read 的问题(依赖于数据库的锁)
a. 使用悲观锁查找数据或者更新数据时，默认加上for update ，表示对当前事务加锁，其他事务暂时不能使用，例如select ... for update
b. 在程序中如何加上悲观锁呢，很简单，直接在session的load方法中添加一个参数即可，例如：
Account a = (Account)session.load(Account.class, 1, LockMode.UPGRADE);
锁的模式：
a.LockMode.None 无锁的机制，Transaction介绍时，切换到此模式
b.LockMode.read 在查询的时候hibernate会自动获取锁
c.LockMode.write insert update hibernate会自动获取锁
d.以上3种锁的模式，是hibernate内部使用的（不需要设置）
e.LockMode.UPGRADE_NOWAIT 是Oracle 支持的索的模式
3.使用乐观锁解决repeatable read 的问题
直接在实体类中添加 version 属性(数据库也会对应生成该字段，初始值为0)，并在其get 方法前加 @version 注解（这里介绍注解方式配置），则在操作过程中每更新一次改行数据则在 version 值上加1，即可在事务提交前判断该数据是否被其他事务修改过
D. repeatable read (事务执行中其他事务无法执行修改或插入操作 较安全)
E. serializable 解决事务隔离级别（顺序执行事务，不并发，实际当中很少使用）
悲观锁
在应用程序中显示地为数据资源加锁.悲观锁假定当前事务操纵数据资源时,肯定还会有其它事务同时访问该数据资源,为了避免当前事务的操作受到干扰,先锁定资源.尽管悲观锁能防止丢失更新和不可重复读这类并发问题,但会影响并发性能.（简单理解，就是每次在操作数据时总是悲观地认为会有别的事务也会来操纵同一数据，从此锁住该笔数据，直到自己操作完成后再解除锁）
假定当前事务操纵数据资源时,不会有其它事务同时访问该数据资源,因此完全依靠数据库的隔离级别来自动管理锁的工作.应用程序采用版本控制手段来避免可能出现的并发问题.（所谓乐观锁，它通常认为多个事务同时操纵同一数据的情况是很少的，因为根本不做数据库层次上的锁定，只是基于数据的版本标识实现应用程序级别上的锁定机制，既保证了多个事务的并发访问，又有效地防止了第二类丢失更新的出现）
LockMode类表示的几种锁定模式
锁定模式 | 描述 |
LockMode.NONE | 如果缓存中存在对象,直接返回该对象的引用,否则通过select语句到数据库中加载该对象,默认值. |
LockMode.READ | 不管缓存中是否存在对象,总是通过select语句到数据库中加载该对象,如果映射文件中设置了版本元素,就执行版本检查,比较缓存中的对象是否和数据库中对象版本一致 |
LockMode.UPGRADE | 不管缓存中是否存在对象,总是通过select语句到数据库中加载该对象,如果映射文件中设置了版本元素,就执行版本检查,比较缓存中的对象是否和数据库中对象的版本一致,如果数据库系统支持悲观锁(如Oracle/MySQL),就执行select...for update语句,如果不支持(如Sybase),执行普通select语句 |
LockMode.UPGRADE_NOWAIT | 和LockMode.UPGRADE具有同样功能,此外,对于Oracle等支持update nowait的数据库,执行select...for update nowait语句,nowait表明如果执行该select语句的事务不能立即获得悲观锁,那么不会等待其它事务释放锁,而是立刻抛出锁定异常 |
LockMode.WRITE | 保存对象时会自动使用这种锁定模式,仅供Hibernate内部使用,应用程序中不应该使用它 |
LockMode.FORCE | 强制更新数据库中对象的版本属性,从而表明当前事务已经更新了这个对象 |
第一类丢失更新:撤销一个事务时,把其它事务已提交的更新数据覆盖.
第二类丢失更新:不可重复读中的特例,一个事务覆盖另一事务已提交的更新数据.
脏读:一个事务读到另一事务未提交的更新数据.
幻读:一个事务读到另一事务已提交的新插入的数据.
不可重复读:一个事务读到另一个事物已提交的更新数据.
l加锁条件:当一个事务执行select语句时,数据库系统会为这个事务分配一把共享锁,锁定被查询的数据.
l解锁条件:数据被读取后,数据库系统立即解除共享锁.
l与其它锁的兼容性:如果数据资源上放置了共享锁,还能再放置共享锁和更新锁.
l并发性能:良好的并发性能.当多个事务读相同数据时,每个事务都会获得一把共享锁,可以同时读锁定的数据.
l加锁条件:当一个事务执行insert,update,delete时,数据库系统会自动对SQL语句操纵的数据资源使用独占锁.如果该数据资源已经有其它锁存在时,无法对其再放置独占锁.
l解锁条件:独占锁一直到事务结束后才能被解除.
l与其它锁的兼容性:独占锁不能和其他锁兼容,如果数据资源已经加上了独占锁, 就不能再放置其它锁,同样,如果已经有了其它锁,就不能放置独占锁.
l并发性能:并发性能较差,只允许有一个事务访问锁定的数据,如果其他事务也需要访问该数据,就必须等待,直到前一个事务结束,解除了独占锁,其它事务才能访问该数据.
l加锁条件:当一个事务进行update操作时,数据库系统会先为事务分配一把更新锁.
l解锁条件:当读取数据完毕,执行更新操作时,会把更新锁升级为独占锁.
l与其它锁的兼容性:更新锁与共享锁兼容,即一个资源可以同时放置更新锁和共享锁,但是最多只能放置一把更新锁,这样,当多个事务更新相同的数据时,只有一个事务能获得更新锁,然后再把更新锁升级为独占锁,其它事务必须等到前一个事务结束后,才能获得更新锁,避免了死锁.
l并发性能:允许多个事务同时读锁定资源,但不允许其它事务修改它.
隔离级别 | 是否出现第一类丢失更新 | 是否出现第二类丢失更新 | 是否出现脏读 | 是否出现幻读 | 是否出现不可重复读 |
Serializable串行化 | 否 | 否 | 否 | 否 | 否 |
RepeatableRead可重复读 | 否 | 否 | 是 | 否 | 否 |
ReadCommited读已提交数据 | 否 | 否 | 是 | 是 | 是 |
ReadUncommited读未提交数据 |
LockMode NONE
No lock required.
LockMode READ
A shared lock. Objects in this lock mode were read from the database in the current transaction, rather than being pulled from a cache （注：也就是从数据库中读数据，绕过了Hibernate的Cache）
LockMode UPGRADE
An upgrade lock.（注：相当于SQL语句select xxx from xxxx for update，也就是把事务的处理交给了数据库）
LockMode UPGRADE_NOWAIT
Attempt to obtain an upgrade lock, using an Oracle-style select for update nowait.
LockMode WRITE
A WRITE lock is obtained when an object is updated or inserted.This lock mode is for internal use only and is not a valid mode for load() or lock() (both of which throw exceptions if WRITE is specified).（注：不能在load的时候用，否则抛出异常）
不过，“纸上得来终觉浅，觉知此事要躬行”，博主做了下实验来比较这些“锁”的不同。
先看代码：
package com.javaye;
import org.hibernate.LockMode;
import org.hibernate.Session;
import org.hibernate.Transaction;
import com.javaye.models.Article;
public class Main {
private static void insert(){
Session session = HibernateSessionFactory.getSession();
Transaction tx = session.beginTransaction();
Article art = new Article();
art.setTitle("AAA");
art.setVisitAmount(0);
session.saveOrUpdate(art);
tx.commit();
}
privatestatic void update(){
Session session = HibernateSessionFactory.getSession();
System.out.println("session:"+session.hashCode());
Transaction tx =session.beginTransaction();
Article art = (Article) session.load(Article.class, 1,LockMode.UPGRADE);
System.out.println("loaded");
art.setVisitAmount(art.getVisitAmount()+1);
session.save(art);
tx.commit();
session.evict(art);
}
private static void work(){
for(int i=0;i<10;i++){
System.out.println(Thread.currentThread().getName()+":"+(i+1)+"times.");
update();
}
}
public static void main(String[] args) throws Exception{
Thread t1 = new Thread(
new Runnable(){
public void run(){
work();
}
}
);
Thread t2 = new Thread(
new Runnable(){
public void run(){
work();
}
}
);
t1.setName("Thread1");
t2.setName("Thread2");
t1.setDaemon(true);
t2.setDaemon(true);
t1.start();
t2.start();
t1.join();
t2.join();
}
}
这是一个多线程程序，每个线程都会从数据库中取出visit_amount,然后加一，再存回数据库，每个线程重复10遍。
请注意蓝色的部分，我们在这里设一个断点，那么用Eclipse调试的时候，到达这个断点的线程就会停下来，由于它的事务还没有commit()，LockMode.UPGRADE的锁就还没有释放，那么另外一个线程中事务就会在load的时候因为不能获得锁而阻塞，那么理论上我们只会看到只有一句“loaded”输出。实验结果证明了我的猜想，LockMode.UPGRADE的情况下，如果一个事务获得了锁，即使另外的事务想读取数据也是不行的，必须等待锁的释放。
那么，改写数据可以吗？笔者又做了一个实验，打开MySQL Query Browser，直接生改数据库，把visit_amount字段的值硬生生改过来，结果发现提交的时候就阻塞了，MySQL的海豚标志一个劲的游泳，这说明，LockMode.UPGRADE级别的锁不是由Hibernate控制的，而是由数据库控制的。
再试一试LockeMode.Read，断点还是设在原来的位置，发现有两次“loaded”输出，证明两个事务可以同时读取这条数据，那么这个锁有什么作用呢？根据我实验的结果，似乎只是为了绕过cache，从数据库直接读取。为了证明我的猜想，我直接通过MySQL Query Browser更改了visit_amount，调试发现，Hibernate是从数据库中读取的新值，而不是cache中的老值。
最后在补充一点，LockMode.UPGRADE加锁是有超时时间的，如果加锁后超过一定的时间不commit，Hibernate会抛出异常。
为了得到最大的性能，一般数据库都有并发机制，不过带来的问题就是数据访问的冲突。为了解决这个问题，大多数数据库用的方法就是数据的锁定。
联系客服
微信登录中...
请勿关闭此页面
