Java 并发编程零：乐观锁与悲观锁

最新推荐文章于 2023-08-10 15:48:56 发布

zhuiqiuuuu

最新推荐文章于 2023-08-10 15:48:56 发布

阅读量292

点赞数

分类专栏： java

java 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

Java 并发编程--乐观锁与悲观锁

CAS与Synchronized的使用情景：　　　

使用场景举例：以MySQL InnoDB为例

乐观锁介绍：

使用举例：以MySQL InnoDB为例

1.概述：首先介绍一些乐观锁与悲观锁:

　　悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

　　乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

乐观锁的一种实现方式-CAS(Compare and Swap 比较并交换)：

2.悲观锁:

　　Java在JDK1.5之前都是靠 synchronized关键字保证同步的，这种通过使用一致的锁定协议来协调对共享状态的访问，可以确保无论哪个线程持有共享变量的锁，都采用独占的方式来访问这些变量。这就是一种独占锁，独占锁其实就是一种悲观锁，所以可以说 synchronized 是悲观锁。

　　悲观锁机制存在以下问题：　　

　　　　　　1. 在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。

　　　　　　2. 一个线程持有锁会导致其它所有需要此锁的线程挂起。

　　　　　　3. 如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

　　对比于悲观锁的这些问题，另一个更加有效的锁就是乐观锁。其实乐观锁就是：每次不加锁而是假设没有并发冲突而去完成某项操作，如果因为并发冲突失败就重试，直到成功为止。

3.乐观锁：

　　乐观锁（ Optimistic Locking ）在上文已经说过了，其实就是一种思想。相对悲观锁而言，乐观锁假设认为数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。

　　上面提到的乐观锁的概念中其实已经阐述了它的具体实现细节：主要就是两个步骤：冲突检测和数据更新。其实现方式有一种比较典型的就是 Compare and Swap ( CAS )。

CAS：

　　CAS是乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。　　　

　　CAS 操作中包含三个操作数 —— 需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。（在 CAS 的一些特殊情况下将仅返回 CAS 是否成功，而不提取当前值。）CAS 有效地说明了“ 我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。 ”这其实和乐观锁的冲突检查+数据更新的原理是一样的。

　　这里再强调一下，乐观锁是一种思想。CAS是这种思想的一种实现方式。

JAVA对CAS的支持：

　　在JDK1.5 中新增 java.util.concurrent (J.U.C)就是建立在CAS之上的。相对于对于 synchronized 这种阻塞算法，CAS是非阻塞算法的一种常见实现。所以J.U.C在性能上有了很大的提升。

　　以 java.util.concurrent 中的 AtomicInteger 为例，看一下在不使用锁的情况下是如何保证线程安全的。主要理解 getAndIncrement 方法，该方法的作用相当于 ++i 操作。

复制代码

 1 public class AtomicInteger extends Number implements java.io.Serializable {  
 2     private volatile int value; 
 3 
 4     public final int get() {  
 5         return value;  
 6     }  
 7 
 8     public final int getAndIncrement() {  
 9         for (;;) {  
10             int current = get();  
11             int next = current + 1;  
12             if (compareAndSet(current, next))  
13                 return current;  
14         }  
15     }  
16 
17     public final boolean compareAndSet(int expect, int update) {  
18         return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  
19     }  
20 }

复制代码

　　在没有锁的机制下,字段value要借助volatile原语，保证线程间的数据是可见性。这样在获取变量的值的时候才能直接读取。然后来看看 ++i 是怎么做到的。

　　 getAndIncrement 采用了CAS操作，每次从内存中读取数据然后将此数据和 +1 后的结果进行CAS操作，如果成功就返回结果，否则重试直到成功为止。

　　而 compareAndSet 利用JNI（Java Native Interface）来完成CPU指令的操作：

1 public final boolean compareAndSet(int expect, int update) {   
2     return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
3 }

　　其中unsafe.compareAndSwapInt(this, valueOffset, expect, update);类似如下逻辑：

1 if (this == expect) {
2     this = update
3     return true;
4 } else {
5     return false;
6 }

　　那么比较this == expect，替换this = update，compareAndSwapInt实现这两个步骤的原子性呢？参考CAS的原理

　CAS原理：

　　CAS通过调用JNI的代码实现的。而compareAndSwapInt就是借助C来调用CPU底层指令实现的。

下面从分析比较常用的CPU（intel x86）来解释CAS的实现原理。下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码：

1 public final native boolean compareAndSwapInt(Object o, long offset,
2                                               int expected,
3                                               int x);

　　　　可以看到这是个本地方法调用。这个本地方法在JDK中依次调用的C++代码为：

复制代码

 1 #define LOCK_IF_MP(mp) __asm cmp mp, 0  \
 2                        __asm je L0      \
 3                        __asm _emit 0xF0 \
 4                        __asm L0:
 5 
 6 inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
 7   // alternative for InterlockedCompareExchange
 8   int mp = os::is_MP();
 9   __asm {
10     mov edx, dest
11     mov ecx, exchange_value
12     mov eax, compare_value
13     LOCK_IF_MP(mp)
14     cmpxchg dword ptr [edx], ecx
15   }
16 }

复制代码

　　如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（lock cmpxchg）。反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）。

CAS缺点：

1）. ABA问题：

　　比如说一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。尽管线程one的CAS操作成功，但可能存在潜藏的问题。如下所示：

　　现有一个用单向链表实现的堆栈，栈顶为A，这时线程T1已经知道A.next为B，然后希望用CAS将栈顶替换为B：

　　　　　　　　　　head.compareAndSet(A,B);

　　在T1执行上面这条指令之前，线程T2介入，将A、B出栈，再pushD、C、A，此时堆栈结构如下图，而对象B此时处于游离状态：

　　此时轮到线程T1执行CAS操作，检测发现栈顶仍为A，所以CAS成功，栈顶变为B，但实际上B.next为null，所以此时的情况变为：

　　　其中堆栈中只有B一个元素，C和D组成的链表不再存在于堆栈中，平白无故就把C、D丢掉了。

　　　从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

复制代码

1 public boolean compareAndSet(
2                V      expectedReference,//预期引用
3 
4                V      newReference,//更新后的引用
5 
6               int    expectedStamp, //预期标志
7 
8               int    newStamp //更新后的标志
9 )

复制代码

　　实际应用代码：

1 private static AtomicStampedReference<Integer> atomicStampedRef = new AtomicStampedReference<Integer>(100, 0);
2 
3 ........
4 
5 atomicStampedRef.compareAndSet(100, 101, stamp, stamp + 1);

2）. 循环时间长开销大：

　　自旋CAS（不成功，就一直循环执行，直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。　

3）. 只能保证一个共享变量的原子操作：

　　当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

CAS与Synchronized的使用情景：　　　

1）对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。

2）对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

　　补充： synchronized在jdk1.6之后，已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

concurrent包的实现：

由于java的CAS同时具有 volatile 读和volatile写的内存语义，因此Java线程之间的通信现在有了下面四种方式：

　　　　　　1）. A线程写volatile变量，随后B线程读这个volatile变量。

　　　　　　2）. A线程写volatile变量，随后B线程用CAS更新这个volatile变量。

　　　　　　3）. A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。

　　　　　　4）. A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

　　Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，volatile变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：

　　　　　　1）. 首先，声明共享变量为volatile；　　

　　　　　　2）. 然后，使用CAS的原子条件更新来实现线程之间的同步；

　　　　　　3）. 同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。

　　AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如下：

JVM中的CAS（堆中对象的分配）：　

　　Java调用new object()会创建一个对象，这个对象会被分配到JVM的堆中。那么这个对象到底是怎么在堆中保存的呢？

　　首先，new object()执行的时候，这个对象需要多大的空间，其实是已经确定的，因为java中的各种数据类型，占用多大的空间都是固定的（对其原理不清楚的请自行Google）。那么接下来的工作就是在堆中找出那么一块空间用于存放这个对象。
　　在单线程的情况下，一般有两种分配策略：

1）. 指针碰撞：这种一般适用于内存是绝对规整的（内存是否规整取决于内存回收策略），分配空间的工作只是将指针像空闲内存一侧移动对象大小的距离即可。

2）. 空闲列表：这种适用于内存非规整的情况，这种情况下JVM会维护一个内存列表，记录哪些内存区域是空闲的，大小是多少。给对象分配空间的时候去空闲列表里查询到合适的区域然后进行分配即可。

　　但是JVM不可能一直在单线程状态下运行，那样效率太差了。由于再给一个对象分配内存的时候不是原子性的操作，至少需要以下几步：查找空闲列表、分配内存、修改空闲列表等等，这是不安全的。解决并发时的安全问题也有两种策略：

　　1）. CAS：实际上虚拟机采用CAS配合上失败重试的方式保证更新操作的原子性，原理和上面讲的一样。

　　2）. TLAB：如果使用CAS其实对性能还是会有影响的，所以JVM又提出了一种更高级的优化策略：每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲区（TLAB），线程内部需要分配内存时直接在TLAB上分配就行，避免了线程冲突。只有当缓冲区的内存用光需要重新分配内存的时候才会进行CAS操作分配更大的内存空间。
　　虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来进行配置（jdk5及以后的版本默认是启用TLAB的）。

4.悲观锁和乐观锁的实战

悲观锁介绍（百科）：

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

使用场景举例：以MySQL InnoDB为例

商品goods表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单，那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。

1如果不采用锁，那么操作方法如下：

//1.查询出商品信息

select status from t_goods where id=1;

//2.根据商品信息生成订单

insert into t_orders (id,goods_id) values (null,1);

//3.修改商品status为2

update t_goods set status=2;

上面这种场景在高并发访问的情况下很可能会出现问题。

前面已经提到，只有当goods status为1时才能对该商品下单，上面第一步操作中，查询出来的商品status为1。但是当我们执行第三步Update操作的时候，有可能出现其他人先一步对商品下单把goods status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。

2使用悲观锁来实现：

在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出goods信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为goods被锁定了，就不会出现有第三者来对其进行修改了。

注：要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。

我们可以使用命令设置MySQL为非autocommit模式：

set autocommit=0;

设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：

//0.开始事务

begin;/begin work;/start transaction; (三者选一就可以)

//1.查询出商品信息

select status from t_goods where id=1 for update;

//2.根据商品信息生成订单

insert into t_orders (id,goods_id) values (null,1);

//3.修改商品status为2

update t_goods set status=2;

//4.提交事务

commit;/commit work;

注：上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交，在这里就不细表了。

上面的第一步我们执行了一次查询操作：select status from t_goods where id=1 for update;

与普通查询不一样的是，我们使用了select…for update的方式，这样就通过数据库实现了悲观锁。此时在t_goods表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

注：需要注意的是，在事务中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，一般SELECT ... 则不受此影响。拿上面的实例来说，当我执行select status from t_goods where id=1 for update;后。我在另外的事务中如果再次执行select status from t_goods where id=1 for update;则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行select status from t_goods where id=1;则能正常查询出数据，不会受第一个事务的影响。

补充：MySQL select…for update的Row Lock与Table Lock

上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。

举例说明：

数据库表t_goods，包括id,status,name三个字段，id为主键，数据库中记录如下;

Sql代码收藏代码

mysql> select * from t_goods;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
| 2 | 1 | 装备 |
+----+--------+------+
2 rows in set
mysql>

mysql> select * from t_goods;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 ||  2 |      1 | 装备 |+----+--------+------+2 rows in setmysql>

注：为了测试数据库锁，我使用两个console来模拟不同的事务操作，分别用console1、console2来表示。

例1: (明确指定主键，并且有此数据，row lock)

console1：查询出结果，但是把该条数据锁定了

Sql代码收藏代码

mysql> select * from t_goods where id=1 for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
+----+--------+------+
1 row in set
mysql>

mysql> select * from t_goods where id=1 for update;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 |+----+--------+------+1 row in setmysql>

console2：查询被阻塞

Sql代码收藏代码

mysql> select * from t_goods where id=1 for update;

mysql> select * from t_goods where id=1 for update;

console2：如果console1长时间未提交，则会报错

Sql代码收藏代码

mysql> select * from t_goods where id=1 for update;
ERROR 1205 : Lock wait timeout exceeded; try restarting transaction

mysql> select * from t_goods where id=1 for update;ERROR 1205 : Lock wait timeout exceeded; try restarting transaction

例2: (明确指定主键，若查无此数据，无lock)

console1：查询结果为空

Sql代码收藏代码

mysql> select * from t_goods where id=3 for update;
Empty set

mysql> select * from t_goods where id=3 for update;Empty set

console2：查询结果为空，查询无阻塞，说明console1没有对数据执行锁定

Sql代码收藏代码

mysql> select * from t_goods where id=3 for update;
Empty set

mysql> select * from t_goods where id=3 for update;Empty set

例3: (无主键，table lock)

console1：查询name=道具的数据，查询正常

Sql代码收藏代码

mysql> select * from t_goods where name='道具' for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
+----+--------+------+
1 row in set
mysql>

mysql> select * from t_goods where name='道具' for update;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 |+----+--------+------+1 row in setmysql>

console2：查询name=装备的数据，查询阻塞，说明console1把表给锁住了

Sql代码收藏代码

mysql> select * from t_goods where name='装备' for update;

mysql> select * from t_goods where name='装备' for update;

console2：若console1长时间未提交，则查询返回为空

Sql代码收藏代码

mysql> select * from t_goods where name='装备' for update;
Query OK, -1 rows affected

mysql> select * from t_goods where name='装备' for update;Query OK, -1 rows affected

例4: (主键不明确，table lock)

console1：查询正常

Sql代码收藏代码

mysql> begin;
Query OK, 0 rows affected
mysql> select * from t_goods where id>0 for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
| 2 | 1 | 装备 |
+----+--------+------+
2 rows in set
mysql>

mysql> begin;Query OK, 0 rows affectedmysql> select * from t_goods where id>0 for update;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 ||  2 |      1 | 装备 |+----+--------+------+2 rows in setmysql>

console2：查询被阻塞，说明console1把表给锁住了

Sql代码收藏代码

mysql> select * from t_goods where id>1 for update;

mysql> select * from t_goods where id>1 for update;

例5: (主键不明确，table lock)

console1：

Sql代码收藏代码

mysql> begin;
Query OK, 0 rows affected
mysql> select * from t_goods where id<>1 for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 2 | 1 | 装备 |
+----+--------+------+
1 row in set
mysql>

mysql> begin;Query OK, 0 rows affectedmysql> select * from t_goods where id<>1 for update;+----+--------+------+| id | status | name |+----+--------+------+|  2 |      1 | 装备 |+----+--------+------+1 row in setmysql>

console2：查询被阻塞，说明console1把表给锁住了

Sql代码收藏代码

mysql> select * from t_goods where id<>2 for update;

mysql> select * from t_goods where id<>2 for update;

console1：提交事务

Sql代码收藏代码

mysql> commit;
Query OK, 0 rows affected

mysql> commit;Query OK, 0 rows affected

console2：console1事务提交后，console2查询结果正常

Sql代码收藏代码

mysql> select * from t_goods where id<>2 for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
+----+--------+------+
1 row in set
mysql>

mysql> select * from t_goods where id<>2 for update;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 |+----+--------+------+1 row in setmysql>

以上就是关于数据库主键对MySQL锁级别的影响实例，需要注意的是，除了主键外，使用索引也会影响数据库的锁定级别

举例：

我们修改t_goods表，给status字段创建一个索引

修改id为2的数据的status为2，此时表中数据为：

Sql代码收藏代码

mysql> select * from t_goods;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
| 2 | 2 | 装备 |
+----+--------+------+
2 rows in set
mysql>

mysql> select * from t_goods;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 ||  2 |      2 | 装备 |+----+--------+------+2 rows in setmysql>

例6: (明确指定索引，并且有此数据，row lock)

console1：

Sql代码收藏代码

mysql> select * from t_goods where status=1 for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 1 | 1 | 道具 |
+----+--------+------+
1 row in set
mysql>

mysql> select * from t_goods where status=1 for update;+----+--------+------+| id | status | name |+----+--------+------+|  1 |      1 | 道具 |+----+--------+------+1 row in setmysql>

console2：查询status=1的数据时阻塞，超时后返回为空，说明数据被console1锁定了

Sql代码收藏代码

mysql> select * from t_goods where status=1 for update;
Query OK, -1 rows affected

mysql> select * from t_goods where status=1 for update;Query OK, -1 rows affected

console2：查询status=2的数据，能正常查询，说明console1只锁住了行，未锁表

Sql代码收藏代码

mysql> select * from t_goods where status=2 for update;
+----+--------+------+
| id | status | name |
+----+--------+------+
| 2 | 2 | 装备 |
+----+--------+------+
1 row in set
mysql>

mysql> select * from t_goods where status=2 for update;+----+--------+------+| id | status | name |+----+--------+------+|  2 |      2 | 装备 |+----+--------+------+1 row in setmysql>

例7: (明确指定索引，若查无此数据，无lock)

console1：查询status=3的数据，返回空数据

Sql代码收藏代码

mysql> select * from t_goods where status=3 for update;
Empty set

mysql> select * from t_goods where status=3 for update;Empty set

console2：查询status=3的数据，返回空数据

Sql代码收藏代码

mysql> select * from t_goods where status=3 for update;
Empty set

mysql> select * from t_goods where status=3 for update;Empty set

谈到了MySQL悲观锁，但是悲观锁并不是适用于任何场景，它也有它存在的一些不足，因为悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是对长事务而言，这样的开销往往无法承受。所以与悲观锁相对的，我们有了乐观锁，具体参见下面介绍：

乐观锁介绍：

乐观锁（ Optimistic Locking ）相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。那么我们如何实现乐观锁呢，一般来说有以下2种方式：

1.使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。用下面的一张图来说明：

如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。但是如果发生有不同的业务操作对同一版本的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。

2.乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

使用举例：以MySQL InnoDB为例

还是拿之前的实例来举：商品goods表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单，那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。

下单操作包括3步骤：

1.查询出商品信息

select (status,status,version) from t_goods where id=#{id}

2.根据商品信息生成订单

3.修改商品status为2

update t_goods

set status=2,version=version+1

where id=#{id} and version=#{version};

那么为了使用乐观锁，我们首先修改t_goods表，增加一个version字段，数据默认version值为1。

t_goods表初始数据如下：

Sql代码收藏代码

mysql> select * from t_goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
| 1 | 1 | 道具 | 1 |
| 2 | 2 | 装备 | 2 |
+----+--------+------+---------+
2 rows in set
mysql>

mysql> select * from t_goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
| 1 | 1 | 道具 | 1 |
| 2 | 2 | 装备 | 2 |
+----+--------+------+---------+
2 rows in set
mysql>

对于乐观锁的实现，我使用MyBatis来进行实践，具体如下：

Goods实体类：

Java代码收藏代码

/**
* ClassName: Goods
* Function: 商品实体.
* date: 2013-5-8 上午09:16:19
* @author chenzhou1025@126.com
*/
public class Goods implements Serializable {
/**
* serialVersionUID:序列化ID.
*/
private static final long serialVersionUID = 6803791908148880587L;
/**
* id:主键id.
*/
private int id;
/**
* status:商品状态：1未下单、2已下单.
*/
private int status;
/**
* name:商品名称.
*/
private String name;
/**
* version:商品数据版本号.
*/
private int version;
@Override
public String toString(){
return "good id:"+id+",goods status:"+status+",goods name:"+name+",goods version:"+version;
}
//setter and getter
}

/**
* ClassName: Goods 
* Function: 商品实体. 
* date: 2013-5-8 上午09:16:19 
* @author chenzhou1025@126.com
*/
public class Goods implements Serializable {
/**
* serialVersionUID:序列化ID.
*/
private static final long serialVersionUID = 6803791908148880587L;
/**
* id:主键id.
*/
private int id;
/**
* status:商品状态：1未下单、2已下单.
*/
private int status;
/**
* name:商品名称.
*/
private String name;
/**
* version:商品数据版本号.
*/
private int version;
@Override
public String toString(){
return "good id:"+id+",goods status:"+status+",goods name:"+name+",goods version:"+version;
}
//setter and getter
}

GoodsDao

Java代码收藏代码

/**
* updateGoodsUseCAS:使用CAS(Compare and set)更新商品信息.
*
* @author chenzhou1025@126.com
* @param goods 商品对象
* @return 影响的行数
*/
int updateGoodsUseCAS(Goods goods);

/**
* updateGoodsUseCAS:使用CAS(Compare and set)更新商品信息. 
*
* @author chenzhou1025@126.com
* @param goods 商品对象
* @return 影响的行数
*/
int updateGoodsUseCAS(Goods goods);

mapper.xml

Xml代码收藏代码

<update id="updateGoodsUseCAS" parameterType="Goods">
<![CDATA[
update t_goods
set status=#{status},name=#{name},version=version+1
where id=#{id} and version=#{version}
]]>
</update>

<update id="updateGoodsUseCAS" parameterType="Goods">
<![CDATA[
update t_goods
set status=#{status},name=#{name},version=version+1
where id=#{id} and version=#{version}
]]>
</update>

GoodsDaoTest测试类

Java代码收藏代码

@Test
public void goodsDaoTest(){
int goodsId = 1;
//根据相同的id查询出商品信息，赋给2个对象
Goods goods1 = this.goodsDao.getGoodsById(goodsId);
Goods goods2 = this.goodsDao.getGoodsById(goodsId);
//打印当前商品信息
System.out.println(goods1);
System.out.println(goods2);
//更新商品信息1
goods1.setStatus(2);//修改status为2
int updateResult1 = this.goodsDao.updateGoodsUseCAS(goods1);
System.out.println("修改商品信息1"+(updateResult1==1?"成功":"失败"));
//更新商品信息2
goods1.setStatus(2);//修改status为2
int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods1);
System.out.println("修改商品信息2"+(updateResult2==1?"成功":"失败"));
}

@Test
public void goodsDaoTest(){
int goodsId = 1;
//根据相同的id查询出商品信息，赋给2个对象
Goods goods1 = this.goodsDao.getGoodsById(goodsId);
Goods goods2 = this.goodsDao.getGoodsById(goodsId);
//打印当前商品信息
System.out.println(goods1);
System.out.println(goods2);
//更新商品信息1
goods1.setStatus(2);//修改status为2
int updateResult1 = this.goodsDao.updateGoodsUseCAS(goods1);
System.out.println("修改商品信息1"+(updateResult1==1?"成功":"失败"));
//更新商品信息2
goods1.setStatus(2);//修改status为2
int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods1);
System.out.println("修改商品信息2"+(updateResult2==1?"成功":"失败"));
}

输出结果：

Shell代码收藏代码

good id:1,goods status:1,goods name:道具,goods version:1
good id:1,goods status:1,goods name:道具,goods version:1
修改商品信息1成功
修改商品信息2失败

good id:1,goods status:1,goods name:道具,goods version:1
good id:1,goods status:1,goods name:道具,goods version:1
修改商品信息1成功
修改商品信息2失败

说明：

在GoodsDaoTest测试方法中，我们同时查出同一个版本的数据，赋给不同的goods对象，然后先修改good1对象然后执行更新操作，执行成功。然后我们修改goods2，执行更新操作时提示操作失败。此时t_goods表中数据如下：

Sql代码收藏代码

mysql> select * from t_goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
| 1 | 2 | 道具 | 2 |
| 2 | 2 | 装备 | 2 |
+----+--------+------+---------+
2 rows in set
mysql>

mysql> select * from t_goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
| 1 | 2 | 道具 | 2 |
| 2 | 2 | 装备 | 2 |
+----+--------+------+---------+
2 rows in set
mysql>

我们可以看到 id为1的数据version已经在第一次更新时修改为2了。所以我们更新good2时update where条件已经不匹配了，所以更新不会成功，具体sql如下：

Sql代码收藏代码

update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};

update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};

这样我们就实现了乐观锁

参考资料：

MySQL事务与锁定命令：http://www.docin.com/p-16805970.html

悲观锁：http://www.cnblogs.com/chenwenbiao/archive/2012/06/06/2537508.html

zhuiqiuuuu

关注

0
点赞
踩
6

收藏

觉得还不错? 一键收藏
0
评论
Java 并发编程零：乐观锁与悲观锁

Java 并发编程--乐观锁与悲观锁目录目录Java 并发编程--乐观锁与悲观锁1.概述：首先介绍一些乐观锁与悲观锁:2.悲观锁:3.乐观锁：CAS：JAVA对CAS的支持：　CAS原理：CAS缺点：CAS与Synchronized的使用情景：　　　concurrent包的实现：JVM中的CAS（堆中对象的分配）：　4.悲观锁和乐观锁的实战...
复制链接

扫一扫