前言
今天主题是悲观锁和乐观锁，很常见的话题了，但是记录一下吧！每个人想法不一样，讲的多少也会不一样，大家随便听听就好，有问题欢迎评论，我是个知错就改的好孩子。今天就来简单了解一下
使用场景
接下来我们了解一下两种锁的使用场景，其实两种锁各有优缺点，所以合适的场合用适合的锁，像乐观锁适用于写比较少的情况下（多读场景）大概就是冲突真的很少发生的时候，这样就可以使用乐观锁，可以省去锁的开销，加大了系统的整个吞吐量。反过来，如果是多写的情况，会经常产生冲突，这就会导致上层应用会不断的进行 retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。简单了解了使用场景，那就看看如何实现吧！
悲观锁
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞，直到它拿到锁。
这里需要注意一下：
共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程
传统的关系型数据库里边就用到了很多这种锁机制， 比如行锁、表锁、读锁、写锁等，都是在做操作之前先上锁。
Java 中 synchronized 和 ReentrantLock 等独占锁也是悲观锁思想的实现。
乐观锁
乐观锁总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候，会判断一下在此期间别人有没有去更新这个数据。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于 write_condition 机制，其实都是提供的乐观锁。
在 Java 中 java.util.concurrent.atomic 包下面的原子变量类，也是使用了乐观锁的一种实现方式 CAS 实现的。
乐观锁一般会使用版本号机制或 CAS 算法实现。
版本号机制
一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数，当数据被修改时，version 值会加一。当线程 A 要更新数据值时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。
CAS算法
compare and swap（比较与交换）是一种有名的无锁算法 无锁编程
即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS 算法涉及到三个操作数
需要读写的内存值 V
进行比较的值 A
拟写入的新值 B当且仅当 V 的值等于 A 时，CAS 通过原子方式用新值 B 来更新 V 的值，否则 不会执行任何操作（比较和替换是一个原子操作）一般情况下是一个自旋操作，即不断的重试。
乐观锁的缺点
ABA 问题是乐观锁一个常见的问题
ABA 问题
如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 "ABA"问题。
JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
循环时间长开销大
自旋 CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给 CPU 带来非常大的执行开销。当然如果 JVM 能支持处理器提供的 pause 指令，那么效率会有一定的提升。
pause 指令有两个作用
第一它可以延迟流水线执行指令（de-pipeline）使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起 CPU 流水线被清空（CPU pipeline flush）从而提高 CPU 的执行效率。
只能保证一个共享变量的原子操作
CAS只对单个共享变量有效，当操作涉及跨多个共享变量时CAS无效。但是从 JDK 1.5 开始，提供了 AtomicReference 类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。所以我们可以使用锁或者利用 AtomicReference 类把多个共享变量合并成一个共享变量来操作。
CAS 与 synchronized 的使用情景
简单的来说
CAS 适用于写比较少的情况下（多读场景，冲突一般较少）
synchronized 适用于写比较多的情况下（多写场景，冲突一般较多）
对于资源竞争较少（线程冲突较轻）的情况，使用 synchronized 同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu 资源；而 CAS 基于硬件实现，不需要进入内核，不需要切换线程，操作自旋机率较少，因此可以获得更高的性能。
对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较大，从而浪费更多的 CPU 资源，效率低于 synchronized。
补充一点： Java 并发编程这个领域中 synchronized 关键字一直都是元老级的角色，很久之前很多人都会称它为 “重量级锁” 。但是，在 JavaSE 1.6 之后进行了一些引入，主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及其它各种优化之后，所以变得在某些情况下并不是那么重了。synchronized 的底层实现主要依靠 Lock-Free 的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量没关系的。在线程冲突较少的情况下，可以获得和 CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS（有点酷哦！）