什么是悲观锁和乐观锁

2.5.9.1. 悲观锁

悲观锁（Pessimistic Lock）：每次在拿数据的时候都会上锁。别人想拿数据就被挡住，直到悲观锁被释放，悲观锁中的共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

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

数据库中的行锁，表锁，读锁（共享锁），写锁（排他锁），以及 syncronized 实现的锁均为悲观锁
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证，

2.5.9.2. 乐观锁

乐观锁（Optimistic Lock）： 不会上锁，但是如果想要更新数据，则会在更新前检查在读取至更新这段时间别人有没有修改过这个数据。如果修改过，则重新读取，再次尝试更新，循环上述步骤直到更新成功（当然也允许更新失败的线程放弃操作）,乐观锁适用于多读的应用类型，这样可以提高吞吐量

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本（version）或者是时间戳来实现，版本记录是最常用的。

乐观控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

2.5.9.3. 锁的实现

悲观锁阻塞事务、乐观锁回滚重试：各有优缺点。乐观锁适用于写比较少的情况下，这样可以省去锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以写比较多的情况下用悲观锁就比较合适。

注意点：

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

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

CAS问题：

CAS ：Compare-and-Swap，即比较并替换，也有叫做 Compare-and-Set 的，比较并设置。

1、比较：读取到了一个值 A，在将其更新为 B 之前，检查原值是否仍为 A（未被其他线程改动）。

2、设置：

• 如果是，将 A 更新为 B，结束。
• 如果不是，则什么都不做。上面的两步操作是原子性的，是瞬间完成，在 CPU 看来就是一步操作。有了 CAS，就可以实现一个乐观锁，允许多个线程同时读取（因为根本没有加锁操作），但是只有一个线程可以成功更新数据，并导致其他要更新数据的线程回滚重试。 CAS 利用 CPU 指令，从硬件层面保证了操作的原子性，以达到类似于锁的效果。

Java 中真正的 CAS 操作调用的 native 方法因为整个过程中并没有“加锁”和“解锁”操作，乐观锁策略也被称为无锁编程。乐观锁其实不是“锁”，它仅仅是一个循环重试 CAS 的算法，但是 CAS 有一个问题那就是会产生 ABA 问题。

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

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