【Java多线程学习5】什么是悲观锁，什么是乐观锁？如何实现乐观锁、乐观锁存在哪些问题

【Java多线程学习5】什么是悲观锁，什么是乐观锁？如何实现乐观锁、乐观锁存在哪些问题

一、什么是悲观锁

概述

悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

像Java中synchronized和ReentrantLock等独占锁就是悲观锁的思想。

• synchronized示例如下：

private Lock lock = new ReentrantLock();public void deal() {//上锁lock.lock();try {//需要同步的操作} finally {//释放锁lock.unlock();}}

• ReentrantLock示例如下：

private Lock lock = new ReentrantLock();public void deal() {//上锁lock.lock();try {//需要同步的操作} finally {//释放锁lock.unlock();}}

高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，若未及时释放锁，悲观锁还可能会存在死锁问题，影响代码的正常运行。

二、什么是乐观锁

概述

乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了

乐观锁的实现方式：版本号机制 或 CAS算法

总体来说：

• 悲观锁通常多用于写比较多的情况下（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如LongAdder），也是可以考虑使用乐观锁的，要视实际情况而定。
• 乐观锁通常多于写比较少的情况下（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考java.util.concurrent.atomic包下面的原子变量类）。

乐观锁的实现方式

乐观锁一般会使用版本号机制 或 CAS算法。CAS算法相对多一些。

方式一：版本号机制

一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会加一。当线程 A 要更新数据值时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

举一个例子：
有一个账户金额表 ，当前账户金额100，表中有一个version字段当前值为1。
线程a，向账户中存100，线程a读取version为1，此时线程b也读取了version的数据为1，并要取20。
线程a，将version=1和金额200一同提交到数据库更新，由于线程a的提交版本等于当前数据库的版本，更新成功。
线程b，也将version=1，金额80提交到数据库更新，由于线程b的提交版本1不等于当前数据库的版本2，操作b的提交被驳回。

方式二：CAS算法

CAS 的全称是 Compare And Swap（比较与交换）算法 ，用于实现乐观锁的一种技术。

CAS算法的思想简单，核心思路是：比较内存中的当前变量的值与预期值是否相等，如果相等则将其值改为新值，如果不相等则当前线程放弃更新，CAS操作失败。

CAS操作设计的三个操作数：

• V：要更新的变量值(Var)
• E：预期值(Expected)
• N：拟写入的新值(New)
  当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。

举一个简单的例子：
线程 a 要修改变量 i 的值为 10，i 原值为 1（V = 1，E=1，N=10，假设不存在 ABA 问题）。
i 与 1 进行比较，如果相等， 则说明没被其他线程修改，可以被设置为 6 。
i 与 1 进行比较，如果不相等，则说明被其他线程修改，当前线程放弃更新，CAS 操作失败。
当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。

乐观锁存在的问题

1、ABA 问题

ABA 问题是乐观锁最常见的问题。
ABA 问题的解决思路是在变量前面追加上版本号或者时间戳。

JDK 1.5 以后的 AtomicStampedReference 类就是用来解决 ABA 问题的，其中的 compareAndSet() 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值

2、只能保证一个共享变量的原子操作

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效 ，也无法实现对代码块或是方法进行原子操作。

3、循环时间开销大

CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。