乐观锁与悲观锁

1、定义

 

乐观锁和悲观锁其实是两种思想，用于解决并发场景下的数据竞争问题。

 

悲观锁：常用的锁基本上都是悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

 

乐观锁：

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，如果更新了这个数据，放弃操作，否则执行操作。

可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

 

乐观锁也称为“无锁”，顾名思义，它是乐观派。乐观锁总是假设对共享资源的访问没有冲突，线程可以不停地执行，无需加锁也无需等待。一旦多个线程发生冲突，乐观锁通常使用一种称为CAS的技术来保证线程执行的安全性。由于没有锁的存在，不可能出现死锁的情况，所以说乐观锁天生免疫死锁。

两种锁的使用场景：

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（读多写少场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

 

2、乐观锁实现方式之CAS

 

CAS算法即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。在JDK1.5 中新增 java.util.concurrent (J.U.C)就是建立在CAS之上的。相对于 synchronized 这种阻塞算法，CAS是非阻塞算法的一种常见实现。所以J.U.C在性能上有了很大的提升。

 

CAS算法涉及到三个操作数

• 需要读写的内存值当前值V
• 旧的预期值 A
• 即将要更新的目标值B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。 CAS 的指令允许算法执行读-修改-写操作，而无需害怕其他线程同时修改变量，因为如果其他线程修改变量，那么 CAS 会检测它（并失败），算法可以对该操作重新计算。

 

举个例子：

1. 如果有多个线程共享的变量i原本等于5，在线程A中，想把它设置为新的值6;

2.用CAS：首先用i去与5对比，发现它等于5，说明没有被其它线程改过，那我就把它设置为新的值6，此次CAS成功，i的值被设置成了6；

3. 如果不等于5，说明i被其它线程改过了（比如现在i的值为2），那么我就什么也不做，此次CAS失败，i的值仍然为2。

 

在这个例子中，i就是V，5就是A，6就是B。

那有没有可能我在判断了i为5之后，正准备更新它的新值的时候，被其它线程更改了i的值呢？

不会的。因为CAS是原子操作，它是一种系统原语，是一条CPU的原子指令，从CPU层保证它的原子性，当多个线程同时使用CAS操作原子个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。

 

以Java中的自增操作(i++)为例，看一下悲观锁和CAS分别是如何保证线程安全的。在Java中自增操作不是原子操作，它实际上包含三个独立的操作：（1）读取i值；（2）加1；（3）将新值写回i

 

因此，如果并发执行自增操作，可能导致计算结果的不准确。在下面的代码示例中：value1没有进行任何线程安全方面的保护，value2使用了乐观锁(CAS)，value3使用了悲观锁(synchronized)。运行程序，使用1000个线程同时对value1、value2和value3进行自增操作，可以发现：value2和value3的值总是等于1000，而value1的值常常小于1000。

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

public class Test {     //value1：线程不安全     private static int value1 = 0;     //value2：使用乐观锁     private static AtomicInteger value2 = new AtomicInteger(0);        //value3：使用悲观锁     private static int value3 = 0;     private static synchronized void increaseValue3(){         value3++;     }            public static void main(String[] args) throws Exception {         //开启1000个线程，并执行自增操作         for(int i = 0; i < 1000; ++i){             new Thread(new Runnable() {                 @Override                 public void run() {                     try {                         Thread.sleep(100);                     } catch (InterruptedException e) {                         e.printStackTrace();                     }                     value1++;                     value2.getAndIncrement();                     increaseValue3();                 }             }).start();         }         //打印结果         Thread.sleep(1000);         System.out.println("线程不安全：" + value1);         System.out.println("乐观锁(AtomicInteger)：" + value2);         System.out.println("悲观锁(synchronized)：" + value3);     } }

AtomicInteger是java.util.concurrent.atomic包提供的原子类，利用CPU提供的CAS操作来保证原子性；除了AtomicInteger外，还有AtomicBoolean、AtomicLong、AtomicReference等众多原子类。

 

2.1、CAS理论实现

 

JUC下的atomic类都是通过CAS来实现的，下面就以AtomicInteger为例来阐述CAS的实现。如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

public class AtomicInteger extends Number implements java.io.Serializable {     //存储整数值，volatile保证可视性     private volatile int value;     //Unsafe用于实现对底层资源的访问     private static final Unsafe unsafe = Unsafe.getUnsafe();     //valueOffset是value在内存中的偏移量     private static final long valueOffset;     //通过Unsafe获得valueOffset     static {         try {             valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));         } catch (Exception ex) { throw new Error(ex); }     }     public final boolean compareAndSet(int expect, int update) {         return unsafe.compareAndSwapInt(this, valueOffset, expect, update);     }     public final int getAndIncrement() {         for (;;) {             int current = get();             int next = current + 1;             if (compareAndSet(current, next))                 return current;         }     } }

　　

源码分析说明如下：

 

（1）getAndIncrement()实现的自增操作是自旋CAS操作：在循环中进行compareAndSet，如果执行成功则退出，否则一直执行。

（2）其中compareAndSet是CAS操作的核心，它是利用Unsafe对象实现的。

（3）Unsafe又是何许人也呢？Unsafe是用来帮助Java访问操作系统底层资源的类（如可以分配内存、释放内存），通过Unsafe，Java具有了底层操作能力，可以提升运行效率；强大的底层资源操作能力也带来了安全隐患(类的名字Unsafe也在提醒我们这一点)，因此正常情况下用户无法使用。AtomicInteger在这里使用了Unsafe提供的CAS功能。

（4）valueOffset可以理解为value在内存中的偏移量，对应了CAS三个操作数(V/A/B)中的V；偏移量的获得也是通过Unsafe实现的。

（5）value域的volatile修饰符：Java并发编程要保证线程安全，需要保证原子性、可视性和有序性；CAS操作可以保证原子性，而volatile可以保证可视性和一定程度的有序性；在AtomicInteger中，volatile和CAS一起保证了线程安全性。

 

Unsafe是CAS的核心类，Java无法直接访问底层操作系统，而是通过本地（native）方法来访问。不过尽管如此，JVM还是开了一个后门：Unsafe，它提供了硬件级别的原子操作。valueOffset为变量值在内存中的偏移地址，unsafe就是通过偏移地址来得到数据的原值的。value当前值，使用volatile修饰，保证多线程环境下看见的是同一个。我们就以AtomicInteger的addAndGet()方法来做说明，先看源代码：

?

1 2 3 4 5 6 7 8 9 10 11

public final int addAndGet(int delta) {     return unsafe.getAndAddInt(this, valueOffset, delta) + delta; } public final int getAndAddInt(Object var1, long var2, int var4){     int var5;     do{         var5 = this.getIntVolatile(var1, var2);     }     while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));     return var5; }

内部调用unsafe的getAndAddInt方法，在getAndAddInt方法中主要是看compareAndSwapInt方法：

?

1	public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

其中四个参数分别表示对象、对象的地址（定位到V）、预期值（A）、修改值（B）。再看unsafe类的方法，这是一个native方法，所以只能继续放看openJDK的代码。public native修饰的方法底层实现都是C/C++。Unsafe中对CAS的实现是C++写的，它的具体实现和操作系统、CPU都有关系。Linux的X86下主要是通过cmpxchgl这个指令在CPU级完成CAS操作的，但在多处理器情况下必须使用lock指令加锁来完成。当然不同的操作系统和处理器的实现会有所不同。当然，Unsafe类还有其它方法法还用不同的用途。比如支持持线程挂起和恢复的park和unpark，LockSupport类底层就是调用了这两个方法。还有支持反射操作的allocateInstance()方法。

 

?

1	public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

 

在unsafe.cpp找到方法CompareAndSwapInt，可以依次看到变量obj、offset、e和x，其中addr就是当前内存位置指针，最终再调用Atomic类的cmpxchg方法。

?

1 2 3 4 5 6

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))   UnsafeWrapper("Unsafe_CompareAndSwapInt");   oop p = JNIHandles::resolve(obj);   jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);   return (jint)(Atomic::cmpxchg(x, addr, e)) == e; UNSAFE_END

 

找到类atomic.hpp，从变量命名上基本可以见名知义。

?

1	static jint cmpxchg (jint exchange_value, volatile jint*  dest, jint compare_value);

和volatile类型，CAS也是依赖不同的CPU会有不同的实现，在src/os_cpu目录下可以看到不同的实现，以atomic_linux_x86.inline.hpp为例，是这么实现的：

?

1 2 3 4 5 6 7 8

inline jint  Atomic::cmpxchg (jint  exchange_value, volatile jint* dest, jint  compare_value) {   int mp = os::is_MP();   __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"                     : "=a" (exchange_value)                     : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)                     : "cc", "memory");   return exchange_value; }

可以看到底层是通过指令cmpxchgl来实现，如果程序是多核环境下，还会先在cmpxchgl前生成lock指令前缀，反之如果是在单核环境下就不需要生成lock指令前缀。为什么多核要生成lock指令前缀？因为CAS是一个原子操作，原子操作隐射到计算机的实现，多核CPU的时候，如果这个操作给到了多个CPU，就破坏了原子性，所以多核环境肯定得先加一个lock指令，不管这个它是以总线锁还是以缓存锁来实现的，单核就不存在这样的问题了。

2.2、CAS缺点

 

1、循环时间长开销很大：比如getAndAddInt方法执行时，如果CAS失败，会一直进行尝试。如果CAS长时间一直不成功，可能会给CPU带来很大的性能开销。 如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline），使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。pause指令能让自旋失败时cpu睡眠一小段时间再继续自旋，从而使得读操作的频率低很多,为解决内存顺序冲突导致的CPU流水线重排的代价也会小很多。

第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

 

2、只能保证一个共享变量的原子操作：当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁来保证原子性。 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，把多个变量放在一个对象里来进行 CAS 操作，所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。

 

3、ABA问题（ABA是乐观锁的的常见问题）

问：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？

很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。就是A先变成了B，然后又变成A。ABA问题的解决思路是在变量前面追加上版本号或者时间戳。

从JDK 1.5开始，JDK的atomic包提供了一个类AtomicStampedReference类来解决ABA问题。其中的compareAndSet方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。AtomicStampedReference通过包装[E,Integer]的元组来对对象标记版本戳stamp，从而避免ABA问题。AtomicStampedReference的compareAndSet()方法定义如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13

public boolean compareAndSet(V   expectedReference,                              V   newReference,                              int expectedStamp,                              int newStamp) {     Pair<V> current = pair;     return         expectedReference == current.reference &&         expectedStamp == current.stamp &&         ((newReference == current.reference &&           newStamp == current.stamp) ||          casPair(current, Pair.of(newReference, newStamp))); }

compareAndSet有四个参数，分别表示：预期引用、更新后的引用、预期标志、更新后的标志。源码部分很好理解预期的引用 == 当前引用，预期的标识 == 当前标识，如果更新后的引用和标志和当前的引用和标志相等则直接返回true，否则通过Pair生成一个新的pair对象与当前pair CAS替换。Pair为AtomicStampedReference的内部类，主要用于记录引用和版本戳信息（标识），定义如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

private static class Pair<T> {     final T reference;     final int stamp;     private Pair(T reference, int stamp)     {         this.reference = reference;         this.stamp = stamp;     }     static <T> Pair<T> of(T reference, int stamp)     {         return new Pair<T>(reference, stamp);     } } private volatile Pair<V> pair;

Pair记录着对象的引用和版本戳，版本戳为int型，保持自增。同时Pair是一个不可变对象，其所有属性全部定义为final，对外提供一个of方法，该方法返回一个新建的Pari对象。pair对象定义为volatile，保证多线程环境下的可见性。在AtomicStampedReference中，大多方法都是通过调用Pair的of方法来产生一个新的Pair对象，然后赋值给变量pair。如set方法：

?

1 2 3 4 5

public void set(V newReference, int newStamp){     Pair<V> current = pair;     if (newReference != current.reference || newStamp != current.stamp)         this.pair = Pair.of(newReference, newStamp); }

 

下面我们将通过一个例子可以可以看到AtomicStampedReference和AtomicInteger的区别。我们定义两个线程，线程1负责将100 —> 110 —> 100，线程2执行 100 —>120，看两者之间的区别。 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

public class Test{     private static AtomicInteger atomicInteger = new AtomicInteger(100);     private static AtomicStampedReference atomicStampedReference = new AtomicStampedReference(100,1);     public static void main(String[] args) throws InterruptedException {         //AtomicInteger         Thread at1 = new Thread(new Runnable(){             @Override             public void run(){                 atomicInteger.compareAndSet(100,110);                 atomicInteger.compareAndSet(110,100);             }         });         Thread at2 = new Thread(new Runnable(){             @Override             public void run(){                 try {                     TimeUnit.SECONDS.sleep(2);      // at1,执行完                 }                 catch (InterruptedException e){                     e.printStackTrace();                 }                 System.out.println("AtomicInteger:" + atomicInteger.compareAndSet(100,120));             }         });         at1.start();         at2.start();         at1.join();         at2.join();         //AtomicStampedReference         Thread tsf1 = new Thread(new Runnable(){             @Override             public void run(){                 try{                     //让 tsf2先获取stamp，导致预期时间戳不一致                     TimeUnit.SECONDS.sleep(2);                 }                 catch (InterruptedException e){                     e.printStackTrace();                 }                 // 预期引用：100，更新后的引用：110，预期标识getStamp() 更新后的标识getStamp() + 1                 atomicStampedReference.compareAndSet(100,110,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);                 atomicStampedReference.compareAndSet(110,100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);             }         });         Thread tsf2 = new Thread(new Runnable(){             @Override             public void run(){                 int stamp = atomicStampedReference.getStamp();                 try{                     TimeUnit.SECONDS.sleep(2);      //线程tsf1执行完                 }                 catch (InterruptedException e) {                     e.printStackTrace();                 }                 System.out.println("AtomicStampedReference:" +atomicStampedReference.compareAndSet(100,120,stamp,stamp + 1));             }         });         tsf1.start();         tsf2.start();     } }

运行结果充分展示了AtomicInteger的ABA问题和AtomicStampedReference解决ABA问题。

 

2.3、CAS与synchronized的使用情景比较

 

一句话： CAS适用于写比较少的情况下（读多写少），synchronized适用于写比较多的情况下（适用于写多场景，冲突一般较多）

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

Java并发编程这个领域中synchronized关键字一直都是元老级的角色，很久之前很多人都会称它为 “重量级锁” 。但是，在JavaSE 1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各种优化之后变得在某些情况下并不是那么重了。synchronized的底层实现主要依靠 Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

 

3、乐观锁实现方式之版本号（version）机制

 

除了CAS，版本号机制也可以用来实现乐观锁。版本号机制的基本思路是在一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加1。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

 

举一个简单的例子：

假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1. 操作员 A 此时将其读出（version=1），并从其帐户余额中扣除 $50（ $100-$50 ）。
2. 在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
3. 操作员 A 完成了修改工作，将数据版本号加1（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4. 操作员 B 完成了操作，也将版本号加1（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

 

需要注意的是，这里使用了版本号作为判断数据变化的标记，实际上可以根据实际情况选用其他能够标记数据版本的字段，如时间戳等。

 

下面以“更新玩家金币数”为例（数据库为MySQL，其他数据库同理），看看悲观锁和版本号机制是如何应对并发问题的。

 

考虑这样一种场景：游戏系统需要更新玩家的金币数，更新后的金币数依赖于当前状态(如金币数、等级等)，因此更新前需要先查询玩家当前状态。

 

下面的实现方式，没有进行任何线程安全方面的保护。如果有其他线程在query和update之间更新了玩家的信息，会导致玩家金币数的不准确。

?

1 2 3 4 5 6 7 8 9

@Transactional public void updateCoins(Integer playerId){     //根据player_id查询玩家信息     Player player = query("select coins, level from player where player_id = {0}", playerId);     //根据玩家当前信息及其他信息，计算新的金币数     Long newCoins = ……;     //更新金币数     update("update player set coins = {0} where player_id = {1}", newCoins, playerId); }

为了避免这个问题，悲观锁通过加锁解决这个问题，代码如下所示。在查询玩家信息时，使用select …… for update进行查询；该查询语句会为该玩家数据加上排它锁，直到事务提交或回滚时才会释放排它锁；在此期间，如果其他线程试图更新该玩家信息或者执行select for update，会被阻塞。

?

1 2 3 4 5 6 7 8 9

@Transactional public void updateCoins(Integer playerId){     //根据player_id查询玩家信息（加排它锁）     Player player = queryForUpdate("select coins, level from player where player_id = {0} for update", playerId);     //根据玩家当前信息及其他信息，计算新的金币数     Long newCoins = ……;     //更新金币数     update("update player set coins = {0} where player_id = {1}", newCoins, playerId); }

版本号机制则是另一种思路，它为玩家信息增加一个字段：version。在初次查询玩家信息时，同时查询出version信息；在执行update操作时，校验version是否发生了变化，如果version变化，则不进行更新。

?

1 2 3 4 5 6 7 8 9 10

@Transactional public void updateCoins(Integer playerId){     //根据player_id查询玩家信息，包含version信息     Player player = query("select coins, level, version from player where player_id = {0}", playerId);     //根据玩家当前信息及其他信息，计算新的金币数     Long newCoins = ……;     //更新金币数，条件中增加对version的校验     update("update player set coins = {0}, version = version + 1 where player_id = {1} and version = {2}", newCoins, playerId, player.version);

 

4、乐观锁和悲观锁优缺点与适用场景

 

乐观锁和悲观锁并没有优劣之分，它们有各自适合的场景；下面从两个方面进行说明。

 

4.1、功能限制

与悲观锁相比，乐观锁适用的场景受到了更多的限制，无论是CAS还是版本号机制。

 

例如，CAS只能保证单个变量操作的原子性，当涉及到多个变量时，CAS是无能为力的（JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，把多个变量放在一个对象里来进行 CAS 操作，所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作），而synchronized则可以通过对整个代码块加锁来处理。再比如版本号机制，如果query的时候是针对表1，而update的时候是针对表2，也很难通过简单的版本号来实现乐观锁。

 

4.2、竞争激烈程度

如果悲观锁和乐观锁都可以使用，那么选择就要考虑竞争的激烈程度：

 

当竞争不激烈 (出现并发冲突的概率小)时，乐观锁更有优势，因为悲观锁会锁住代码块或数据，其他线程无法同时访问，影响并发，而且加锁和释放锁都需要消耗额外的资源。

当竞争激烈(出现并发冲突的概率大)时，悲观锁更有优势，因为乐观锁在执行更新时频繁失败，需要不断重试，浪费CPU资源。