乐观锁和悲观锁

悲观锁

    总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿 数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资 源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线 程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁 等，读锁，写锁等，都是在做操作之前先上锁。Java 中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。

乐观锁

  总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上 锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以 使用版本号机制和 CAS 算法实现。乐观锁适用于多读的应用类型，这样可以提 高吞吐量，像数据库提供的类似于 write_condition 机制，其实都是提供的乐 观锁。在 Java 中 java.util.concurrent.atomic 包下面的原子变量类就是使用了 乐观锁的一种实现方式 CAS 实现的。

 

悲观锁的实现方法就是通过将线程挂起，将线程从用户态转变成内核态

 

乐观锁的实现方式是让线程进行自旋或者版本检查

 

乐观锁常见的两种实现方式

乐观锁一般会使用版本号机制或 CAS 算法实现

1. 版本号机制

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

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。

2. CAS 算法

CAS算法 即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数

• 需要读写的内存值 V
• 进行比较的值 A
• 拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。 

（文字比较抽象，看自选锁的代码就能懂了，其实下面的代码就是 CAS算法，和当时学操作系统的时候差不多）

什么是自旋锁？

自旋锁（spinlock）：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。

获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。

它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，”自旋”一词就是因此而得名。

Java如何实现自旋锁？

下面是个简单的例子：

public class SpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    public void lock() {
        Thread current = Thread.currentThread();
        // 利用CAS
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}

就是一般的会产生线程冲突的代码处理方式一般为

lock（）；

//会产生冲突的代码

unlock（）；

仔细回想一下当初学操作系统的时候就懂了 

参考链接  这个链接还有深入讲解了 自旋锁

 

乐观锁的缺点

1.ABA 问题

     ABA 问题是指  如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然 是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能 的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就 会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 "ABA"问题。 JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是 否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为 给定的更新值。

2 循环时间长开销大

自旋 CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给 CPU 带来非常大的执行开销。 如果 JVM 能支持处理器提供的 pause 指令那么 效率会有一定的提升，pause 指令有两个作用，第一它可以延迟流水线执行指 令（de-pipeline）,使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体 实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时 候因内存顺序冲突（memory order violation）而引起 CPU 流水线被清空 （CPU pipeline flush），从而提高 CPU 的执行效率。

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

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是 从 JDK 1.5 开始，提供了 AtomicReference 类来保证引用对象之间的原子性，你 可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利 用 AtomicReference 类把多个共享变量合并成一个共享变量来操作。

CAS 与 synchronized 的使用情景