【Java基础】乐观锁和悲观锁的实现

一、乐观锁

1. 概念
乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁。但是如果想要更新数据，则会在更新前检查在读取至更新这段时间别人有没有修改过这个数据。如果修改过，则重新读取，再次尝试更新，循环上述步骤直到更新成功（当然也允许更新失败的线程放弃操作）,乐观锁适用于多读的应用类型，这样可以提高吞吐量。
乐观控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

2. 实现方式

• CAS机制
  什么是CAS呢？Compare-and-Swap，即比较并替换，也有叫做Compare-and-Set的，比较并设置。
  （1）比较：读取到了一个值A，在将其更新为B之前，检查原值是否仍为A（未被其他线程改动）。
  （2）设置：如果是，将A更新为B，结束。[1]如果不是，则什么都不做。
  上面的两步操作是原子性的，可以简单地理解为瞬间完成，在CPU看来就是一步操作。
  有了CAS，就可以实现一个乐观锁，允许多个线程同时读取（因为根本没有加锁操作），但是只有一个线程可以成功更新数据，并导致其他要更新数据的线程回滚重试。 CAS利用CPU指令，从硬件层面保证了操作的原子性，以达到类似于锁的效果。

  Java中真正的CAS操作调用的native方法
  因为整个过程中并没有“加锁”和“解锁”操作，因此乐观锁策略也被称为无锁编程。换句话说，乐观锁 其实不是“锁”，它仅仅是一个循环重试CAS的算法而已，但是CAS有一个问题那就是会产生ABA问题，什么是ABA问题，以及如何解决呢？

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

  ABA 问题解决：
  我们需要加上一个版本号（Version）,在每次提交的时候将版本号+1操作，那么下个线程去提交修改的时候，会带上版本号去判断，如果版本修改了，那么线程重试或者提示错误信息~

• 版本号机制
  版本号机制，是在数据库中添加一个version字段，用于标识哪个版本。每当修改一次数据时候，会将版本号加1。

  • 当查询数据时候，将数据中的版本号一起查询出来。
  • 接着修改数据，准备提交更新后的数据到数据库时候，再次查询数据库中版本号。
  • 判断当前查询的版本号是否和第一次查询的一样，如果一样，则进行操作，否则重试。

二、悲观锁

1. 概念

   悲观锁是一种悲观思想，每次去拿数据的时候都认为别人会修改。所以每次在拿数据的时候都会上锁。这样别人想拿数据就被挡住，直到悲观锁被释放，悲观锁中的共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

   但是在效率方面，处理加锁的机制会产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，如果已经锁定了一个线程A，其他线程就必须等待该线程A处理完才可以处理。

   数据库中的行锁，表锁，读锁（共享锁），写锁（排他锁），以及syncronized实现的锁均为悲观锁。

   悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证：
   

2. 实现方式

   • 可以对代码块加锁，也可以对数据加锁。
   • Java中可以使用synchronized同步代码块。
   • 数据库中可以使用排它锁。

三、如何选择

根据两种锁的适用场景，它们各有优缺点，悲观锁阻塞事务，乐观锁回滚重试，不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去锁的开销，加大了系统的整个吞吐量。

但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

注意点：

1、乐观锁并未真正加锁，所以效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。

2、悲观锁依赖数据库锁，效率低。更新失败的概率比较低。