通俗易懂讲乐观锁与悲观锁

本文主要是介绍通俗易懂讲乐观锁与悲观锁，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

浅谈乐观锁与悲观锁

乐观锁和悲观锁是Java并发编程中的两个概念。使用乐观锁和悲观锁可以解决并发编程中数据不一致性、死锁、性能差等问题，乐观锁与悲观锁的实行方式不同，所以其特性也不近相同，下文将详细介绍两者的特性与适用场景。

《熊出没》相信大家都了解过，接下来我将用《熊出没》中吉吉国王的视角来通俗易懂的讲述乐观锁与悲观锁。

悲观锁-总有刁民想害朕

吉吉国王在昨天摘了很多香蕉，在睡觉前没有吃完，于是它将剩下的香蕉存储起来留在第二天吃，由于吉吉国王身居高位，对于个人的饮食安全比较在意，因此它在扒出香蕉前总是在想：总有刁民想害朕，一定有其他猴子偷吃（数据减少、扣库存）本王的香蕉，或者给本王的香蕉下毒（修改数据），在吃之前我一定要好好检查一下。

悲观锁总是假设最坏的情况，即每次访问数据的时候，数据均被其他线程修改，所以悲观锁在每次使用时都会对所需资源进行上锁，如果其他线程获取该资源时会被阻塞，需要等待当前线程将资源释放。

Java悲观锁举例

synchronized关键字：synchronized关键字可以用来修饰方法或代码块，确保在同一时间只有一个线程可以访问被synchronized修饰的方法或代码块。当一个线程进入synchronized代码块时，会自动获取对象的锁，其他线程需要等待该线程释放锁才能访问。

public synchronized void synchronizedMethod() {// synchronized方法体
}// 或者
public void someMethod() {synchronized(this) {// synchronized代码块}
}

ReentrantLock类：ReentrantLock是Java中的一种可重入锁，它提供了与synchronized类似的加锁和释放锁的功能，但相比synchronized更加灵活，可以支持公平锁和非公平锁，并且提供了更多的高级功能，如可中断锁、定时锁等。

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;public class Example {private Lock lock = new ReentrantLock();public void someMethod() {lock.lock(); // 获取锁try {// 锁保护的代码块} finally {lock.unlock(); // 释放锁}}
}

ReadWriteLock接口：ReadWriteLock接口提供了读写锁的功能，可以允许多个线程同时读取共享资源，但只允许一个线程写入共享资源。ReentrantReadWriteLock是ReadWriteLock接口的默认实现。

import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;public class Example {private ReadWriteLock rwLock = new ReentrantReadWriteLock();public void readMethod() {rwLock.readLock().lock(); // 获取读锁try {// 读取共享资源} finally {rwLock.readLock().unlock(); // 释放读锁}}public void writeMethod() {rwLock.writeLock().lock(); // 获取写锁try {// 写入共享资源} finally {rwLock.writeLock().unlock(); // 释放写锁}}
}

悲观锁适用场景与缺陷

适用场景：悲观锁的核心观念是：每次方式资源时，该资源均被修改，因此悲观锁适用于写多、读少的业务场景。

悲观锁缺陷：由于悲观锁每次使用时都需要对资源进行加锁，如果与其他线程存在资源竞争关系则可能会导致死锁互相阻塞的问题。

乐观锁-人之初，性本善

知识补充：

乐观锁版本机制： 一般是在数据表中加上一个数据版本号 version 或update_time字段，表示数据被修改的次数。

爱吃蜂蜜的熊大和熊二采集了一罐蜂蜜，它们约定每人每天吃一口（并发更新），吃完后在罐子上划上属于自己的线（线-版本），以证明自己吃过。熊二有时会贪吃，偶尔吃完一口还想再吃一口（数据被修改）。有一天，熊二不受控制地吃了两次，画了两道线。轮到熊大吃蜂蜜时，它发现罐子上的横线数量与上次吃蜂蜜时不一致（版本不一致），熊大意识到熊二又在嘴馋了，心里暗自嘀咕着这家伙真是没完没了。

出于熊大和熊二两兄弟间的信任，或者相信“天下还是好人多”，乐观锁总是相信共享资源没有被其他线程修改过，判断逻辑是通过版本机制或者CAS（compare and swap）算法实现。

版本机制

假设线程1要使用乐观锁对id为1的数据做修改，在修改前，需要先查询数据数据版本，然后再执行其他逻辑，在执行其他逻辑的期间，该数据可能被其他线程所修改，在下边的案例中修改了对应的数据，此时线程1并不知道其他线程修改了数据，为了判断数据是否被修改，线程1在更新时在where条件中校验数据版本，如果数据被修改过，则version版本不可能为1，因此，可以通过update语句的影响行数判断数据是否被修改。如果修改失败，则根据业务可使用重试机制。

create table orders
(id      int auto_incrementprimary key,price   decimal       null comment '金额',version int default 1 null comment '版本'
);# 线程1查看数据版本
select version from orders where id = 1;# 线程2修改了orders
update orders set price = 20.00, version = 2 where id = 1 and version = 1;# 线程1做修改orders的操作
update orders set price = 30.00, version = 2 where id = 1 and version = 1;

使用Java代码模拟乐观锁的情况：

import java.util.concurrent.atomic.AtomicInteger;class OptimisticLock {private AtomicInteger version = new AtomicInteger(0);private String data;public OptimisticLock(String data) {this.data = data;}// 读取数据public String readData() {return data;}// 更新数据public void updateData(String newData) {// 模拟在更新数据之前检查版本int oldVersion = version.get();// 模拟执行更新逻辑前，其他线程更新数据时，版本已经发生变化simulateConcurrency(); if (oldVersion != version.get()) {System.out.println("Data update failed due to concurrent modification.");//可按业务需求来进行重试return;}data = newData;version.incrementAndGet();System.out.println("Data updated successfully. New version: " + version.get());}// 模拟并发访问，延迟一段时间private void simulateConcurrency() {try {Thread.sleep(1000); // 模拟并发情况下的延迟} catch (InterruptedException e) {e.printStackTrace();}}
}public class Main {public static void main(String[] args) {OptimisticLock lock = new OptimisticLock("Initial data");// 线程1尝试更新数据new Thread(() -> {lock.updateData("Updated by Thread 1");}).start();// 线程2尝试更新数据new Thread(() -> {lock.updateData("Updated by Thread 2");}).start();}
}

在这个示例中，OptimisticLock 类代表一个具有乐观锁机制的数据对象。version 字段用于记录数据的版本号，每次更新数据时，版本号都会递增。在 updateData 方法中，首先检查旧版本和当前版本是否一致，如果一致则更新数据并递增版本号，否则认为更新失败。模拟了并发情况下的延迟和版本检查。

CAS算法

CAS：compoare and swap，比较和交换，CAS也可以理解为一种版本机制：比较期望值和待更新值是否一致，如果一致，则修改当前值为新值。CAS 是一个原子操作，底层依赖于一条 CPU 的原子指令。

CAS中的三个角色：

待更新值：Var，简写V
期望值：Expected
新值：New（待写入值）

一只熊一天能吃一次蜂蜜，熊二贪嘴吃了两次蜂蜜，罐子上有两个杠，熊大期望熊二吃了一次，罐子上一个杠，轮到熊大吃蜂蜜时，熊大实际看到罐子上两个杠，与期望值不符，熊大没有吃蜂蜜，去告诉了妈妈（值不相等，不修改，抛出异常），第二天熊二知错就改，吃了一次蜂蜜，熊大看到与自己期望的一条杠一致，开心的吃了蜂蜜，画上了第二条杠(当前值与期望值一致，写入新值)。

CAS算法ABA问题

如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 "ABA"问题。

ABA 问题的解决思路是在变量前面追加上版本号或者时间戳。JDK 1.5 以后的 AtomicStampedReference 类就是用来解决 ABA 问题的，其中的 compareAndSet() 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

该段原地址：Java Guide ABA问题