目录

1.乐观锁和悲观锁

2.读写锁和普通的互斥锁

3.重量级锁和轻量级锁

4. 挂起等待锁和自旋锁

4. 公平锁和不公平锁

5. 可重入锁 和 不可重入锁

6. synchronized 的锁总结

7. CAS 

7.1 CAS 伪代码

7.2 CAS是怎么实现的 

7.3 CAS 实现原子类 

7.4  实现自旋锁

8. CAS 的 ABA 问题

8.1解决方案

8.2 相关面试题

1.乐观锁和悲观锁

1）乐观锁，即预期锁冲突的概率很低。

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁

例如，下一波疫情即使来了，也不用担心，生活还能正常运转，很多吃的和用品都可以买到，不需要专门做准备。（乐观锁）

2）悲观锁，即预期锁冲突的概率很高

3.重量级锁和轻量级锁

CPU 提供了 " 原子操作指令 "。

操作系统基于 CPU 的原子指令 , 实现了 mutex 互斥锁。

JVM 基于操作系统提供的互斥锁 , 实现了 synchronized 和 ReentrantLock 等关键字和类。

注意, synchronized 并不仅仅是对 mutex 进行封装, 在 synchronized 内部还做了很多其他的工作

synchronized 开始是一个轻量级锁。 如果锁冲突比较严重, 就会变成重量级锁

2）重量级锁

大量的内核态用户态切换

很容易引发线程的调度

3）轻量级锁 

少量的内核态用户态切换。

不太容易引发线程调度。

4） 理解用户态 vs 内核态

想象去银行办业务

4. 挂起等待锁和自旋锁

挂起等待锁是 重量级锁 的实现方式

优点 : 没有放弃 CPU, 不涉及线程阻塞和调度 , 一旦锁被释放 , 就能第一时间获取到锁 .

缺点 : 如果锁被其他线程持有的时间比较久 , 那么就会持续的消耗 CPU 资源 . ( 而挂起等待的时候是

不消耗 CPU 的

4. 公平锁和不公平锁

7. CAS 

我们假设内存中的原数据 V ，旧的预期值 A ，需要修改的新值 B 。

1. 比较 A 与 V 是否相等。（比较）

2. 如果比较相等，将 B 写入 V 。（交换）

3. 返回操作是否成功。

7.1 CAS 伪代码

boolean CAS(address, expectValue, swapValue) {
 if (&address == expectedValue) {
   &address = swapValue;
        return true;
   }
    return false; 
}

7.2 CAS是怎么实现的 

java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作；

unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg ；

Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性

7.3 CAS 实现原子类 

public class Demo5 {
    public static void main(String[] args) throws InterruptedException {
        AtomicInteger num = new AtomicInteger(0);

        Thread t1 = new Thread(() ->{
            for (int i = 0; i < 5000; i++) {
                //这个方法相当于num++
                num.getAndIncrement();
            }
        });

        Thread t2 = new Thread(() ->{
           for (int i = 0; i < 5000; i++) {
               //这个方法相当于num++
               num.getAndIncrement();
           }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(num.get());
    }
}

public class SpinLock {
    private Thread owner = null;
    public void lock(){
        // 通过 CAS 看当前锁是否被某个线程持有. 
        // 如果这个锁已经被别的线程持有, 那么就自旋等待. 
        // 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程. 
        while(!CAS(this.owner, null, Thread.currentThread())){
       }
   }
    public void unlock (){
        this.owner = null;
   }
}

 异常的过程：

1) 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.

2) 线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.

3) 在线程2 执行之前, A的朋友正好给A转账 50, 账户余额变成 100 

4) 轮到线程2 执行了, 发现当前存款为 100, 和之前读到的 100 相同, 再次执行扣款操作

最后取出来100

 这个时候, 扣款操作被执行了两次，就是ABA引起的

8.1解决方案

给要修改的值, 引入版本号.。在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期。

CAS 操作在读取旧值的同时 , 也要读取版本号 .

真正修改的时候 ,

     如果当前版本号和读到的版本号相同 , 则修改数据 , 并把版本号 + 1。

     如果当前版本号高于读到的版本号 . 就操作失败 ( 认为数据已经被修改过了 )。

 在 Java 标准库中提供了 AtomicStampedReference 类. 这个类可以对某个类进行包装, 在内部就提 供了上面描述的版本管理功能。

8.2 相关面试题

全称 Compare and swap, 即 "比较并交换". 相当于通过一个原子的操作, 同时完成 "读取内存, 比较是否相等, 修改内存" 这三个步骤. 本质上需要 CPU 指令的支撑。

 2) ABA问题怎么解决？

给要修改的数据引入版本号 . 在 CAS 比较数据当前值和旧值的同时 , 也要比较版本号是否符合预期。

如果发现当前版本号和之前读到的版本号一致 , 就真正执行修改操作 , 并让版本号自增 ; 如果发现当前版本号比之前读到的版本号大, 就认为操作失败。