🍑一. JUC包（java.util.concurrent）下的常见类

juc包下的所有类都是提供多线程并发编程用的，不仅满足线程安全而且效率也很高

ReentranLock是可重入锁，具体用法：

Lock lock = new ReentrantLock();
        try{
            lock.lock(); //锁对象加锁，只有一个线程获取到锁
            //需要保证线程安全的代码
        }finally{
            lock.unlock(); //不管是否出现异常都需要释放锁
        }

lock提供了更多获取锁的方式：

🍬synchronized与lock的区别：

🍂synchronized是一个关键字在JVM内部实现的，lock是标准库的一个类在JVM外部实现

🍂语法上看，sychronized是自动加锁与释放锁，lock是手动的加锁与释放锁，相对lock比较灵活，但需要保证不管是否发生异常都需要释放锁

🍂lock获取锁的方式相对更加丰富，提供了多种api

🍂从效率上看，当线程冲突严重时，lock性能要高很多

🍖线程冲突严重时lock性能高的原因：

synchronized在释放锁以后，之前因为申请锁失败而阻塞的线程，都会再次竞争

lock是基于aqs来实现，aqs是一个双端队列专门用来管理线程的状态，竞争失败的线程就入队列并设置状态，释放锁后把队列中的线程引用拿出来并设置状态（获取到锁）

🍬如何选择使用哪个锁呢？

🍃当锁竞争不激烈的时候，使用synchronized效率高，自动释放更方便

🍃当锁竞争激烈的时候，使用lock，搭配tryLock更灵活控制加锁的行为，而不是死等

🍃需要使用公平锁的时候使用lock，lock默认是非公平的锁，但可以通过构造方法传入true开启公平模式（后面在锁策略中介绍）

🍉二. 常见的锁策略

🌴1. 乐观锁与悲观锁

悲观锁：大部分时间来看，都是存在线程冲突的（悲观的看待问题），每次拿数据的时候都认为会修改，所以每次拿数据的时候都先加锁，完成执行操作后再释放锁

乐观锁：大部分时间来看，是不存在线程冲突的（乐观的看待问题），每次都直接执行修改数据的操作，在数据提交更新的结果时，才会检测是否产生并发冲突，返回是否修改成功的结果，让程序自行处理逻辑

🍖乐观锁最重要的就是检测出是否发生线程冲突，这里引入一个版本号（version）解决：

主存中有变量和一个版本号，两个线程同时将主存中的信息读到各自的寄存器中，然后进行修改，线程1先修改然后往主存中写，然后对比版本号，相同的话version++，当线程2执行相同操作时发现版本号不相同，就写入失败

具体过程如下图：

乐观锁从Java层面来看是无锁操作，直接修改共享变量

返回true，修改成功

返回false，修改失败

🌾2. 自旋锁（Spin Lock）

线程在竞争锁失败的时候会进入阻塞状态，放弃CPU，需要过很久才能被再次调度，但是实际上，虽然当前竞争锁失败但是没有过多久就竞争到锁，没必要放弃CPU，这个时候就可以使用自旋锁来解决这种情况

自旋锁实际也是Java层面的无锁操作

while(true){
    boolean result = 乐观锁方式修改数据;
    if(result) break;
}

说明：如果获取锁失败，就立即在尝试获取锁，无限循环直到获取到锁，一旦其他线程释放锁，就能第一时间获取到锁

如果满足乐观锁的使用条件：冲突概率比较小，如果发生冲突也能够很快的得到执行

一般来说乐观锁都考虑结合自旋锁来操作

🌵3. 读写锁

多个线程在数据读取时不会存在线程安全问题，但多个线程的写与读和写需要进行加锁，如果这两种场景下都用同一个锁就会产生很大的性能损耗，所以就要使用读写锁

读写锁就是对读和写操作区分对待，Java标准库中提供了ReentrantReadWriteLock类，实现了读写锁

ReentrantReadWriteLock.ReadLock表示一个读锁，提供了lock/unlock方法进行加锁释放锁

ReentrantReadWriteLock.WriteLock表示一个写锁，提供了lock/unlock方法进行加锁释放锁

关于读写锁：

🍁读与读之间不互斥

🍁写与写之间互斥

🍁读与写之间互斥

🍬读写锁适用频繁读，不频繁写的场景中

🌳4. 重量级锁与轻量级锁

重量级锁：加锁机制重度依赖OS提供的mutex

大量的内核态与用户态切换

容易引发线程的调度

操作成本高

轻量级锁：加锁机制尽可能不用mutex，而是尽量在用户态代码完成

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

不太容易引发线程调度

操作成本相对低

🌴5. 公平锁与非公平锁

非公平锁：不以申请锁的时间先后顺序来获取到锁

缺陷：可能出现线程饥饿现象

优点：效率更高

公平锁：以申请锁的时间先后顺序来获取到锁

🍂synchronized是非公平锁，因为多个线程之间申请锁是竞争关系，不存在时间先后顺序

🍂lock默认下是非公平锁，但可以修改构造方法的参数来启用公平锁

🌾6. 可重入锁与不可重入锁

可重入锁：同一个线程可以重复申请到同一个对象的锁

不可重入锁：同一个线程不可以重复申请到同一个对象的锁

Java中，只要以Reentrant开头命名的锁都是可重入锁，lock实现类，synchronized关键字锁都是可重入锁

🍋三. CAS

🌴1. 认识CAS

CAS全称Compared And Swap（比较并交换），是jdk提供的一种乐观锁的实现，能够满足线程安全，以乐观锁的方式修改变量

比较并交换（比较，+1，交换）为一条CAS指令，是线程安全的

此处所谓的CAS指的是CPU提供了一个单独的CAS指令，通过这个指令可以完成比较并交换的过程

🍬CAS操作步骤：

🍀从主存拿值读取到自己的工作内存中，记为值A，执行修改操作后，值为B，主存的最新值记为C

🍀将B写入主存时比较A与主存的最新值C是否相等

🍀相等就写入成功，不相等就写入失败

🍀返回修改操作的结果

画图说明如下：

🌾2. jdk如何实现CAS

jdk提供了一个Unsafe的类，来执行cas的操作

jdk中unsafe提供的cas方法，是基于操作系统提供的cas方法，又是基于CPU提供的cas硬件支持，且CPU使用了lock加锁

简单说，Unsafe是基于操作系统和CPU提供的cas来实现的

🌵3. CAS的常见应用

Java的java.util.concurrent.atomic包下都是使用了cas来保证线程安全的，例如：++，--，!flag

原因：++，--，!flag这种操作执行速度非常快，很快能得到执行，使用cas+自旋锁效率更高

既能够保证线程安全又能够比synchronized高效，因为不涉及竞争锁的竞争，线程要等待

典型的就是AtomicInteger类:

🍂addAndGet(int delta)        i += delta

🍂decrementAndGet()          --i

🍂getAndDecrement()          i--

🍂incrementAndGet()          ++i

🍂getAndIncrement()           i++

👁‍🗨️例如：执行1000次n++和n--操作看结果

import java.util.concurrent.atomic.AtomicInteger;
public class AutoInt {
    //共享变量n初始值为0
    private static AtomicInteger n = new AtomicInteger(0);
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(new Runnable() {
            @Override
            public void run() {
                for(int i = 0;i < 1000;i++){
                    n.getAndIncrement(); //1000次n++;
                }
            }
        });
        Thread t2 = new Thread(new Runnable() {
            @Override
            public void run() {
                for(int i = 0;i < 1000;i++) {
                    n.getAndDecrement(); //1000次n--
                }
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(n);
    }
}

结果：打印结果为0

🌳4. CAS中的ABA问题

在没有引入版本号的情况下，CAS是基于变量的值，在读和写的时候比较的，但这个时候会存在下面的一个问题：

从中发现，如果在当前线程写入值进行比较的时候，如果有其他线程对主存中的的值进行修改，修改为当前线程从主存读取的值的时候，当前线程仍然能写入成功，但是存在线程安全问题

🍖ABA问题的解决？

引入版本号，线程每次修改共享变量的时候版本号+1，比较的时候比较读和写时候版本号是否相同，相同的话写入成功，否则写入失败

jdk中，提供了一个AtomicStampedReference<E>的类，这个类可以对某个类进行包装，在其内部就提供了版本号的管理

🍏四. Synchronized的原理

🌴1.synchronized的特性

synchronized是基于对象头加锁，实现线程间的同步互斥

同步互斥：对同一个对象进行加锁的多个线程，同一个时间只有一个线程获取到锁，相当于多个线程获取锁执行同步代码是互斥的

🍬synchronized加锁操作，，只涉及对象头状态升级能升级不能降级，升级的过程：

无锁

偏向锁

轻量级锁

重量级锁

🌾2. 加锁的工作过程

偏向锁：第一次进入的线程，或是这个线程再次申请同一个对象锁

偏向锁不是真的 "加锁", 只是给对象头中做一个 "偏向锁的标记", 记录这个锁属于哪个线程.如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)如果后续其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态

轻量级锁：随着其他线程的竞争进入轻量级锁状态，CAS+（自适应的）自旋锁

自适应：自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源，因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了，也就是所谓的 "自适应"

重量级锁：竞争锁进一步激烈，就会升级为重量级锁（使用操作系统mutex加锁）

🌵3. JVM对synchronized的优化方案

锁消除，前提：变量只有一个线程可以操作

比如这段代码：

StringBuffer sb = new StringBuffer();
        sb.append("a");
        sb.append("b");
        sb.append("c");
        sb.append("d");

此时每个 append 的调用都会涉及加锁和解锁，但如果只是在单线程中执行这个代码, 那么这些加

锁解锁操作是没有必要的, 白白浪费了一些资源开销

锁粗化，前提：变量是多个线程可以使用，，但是一个线程出现多次连续sychronized加锁