JUC 多线程介绍

1、 线程的生命周期

  • 新建状态（New）：当线程对象对创建后，即进入了新建状态，如：Thread t = new MyThread();

  • 就绪状态（Runnable）：当调用线程对象的start()方法（t.start();），线程即进入就绪状态。处于就绪状态的线程，只是说明此线程已经做好了准备，随时等待CPU调度执行，并不是说执行了t.start()此线程立即就会执行；

  • 运行状态（Running）：当CPU开始调度处于就绪状态的线程时，此时线程才得以真正执行，即进入到运行状态。注：就 绪状态是进入到运行状态的唯一入口，也就是说，线程要想进入运行状态执行，首先必须处于就绪状态中；

  • 阻塞状态（Blocked）：处于运行状态中的线程由于某种原因，暂时放弃对CPU的使用权，停止执行，此时进入阻塞状态，直到其进入到就绪状态，才 有机会再次被CPU调用以进入到运行状态。根据阻塞产生的原因不同，阻塞状态又可以分为三种：

    1.等待阻塞：运行状态中的线程执行wait()方法，使本线程进入到等待阻塞状态；

    2.同步阻塞 – 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态；

    3.其他阻塞 – 通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

  • 死亡状态（Dead）：线程执行完了或者因异常退出了run()方法，该线程结束生命周期。

在这里插入图片描述

  • Java多线程的就绪、运行和死亡状态：

    就绪状态转换为运行状态：当此线程得到处理器资源；

    运行状态转换为就绪状态：当此线程主动调用yield()方法或在运行过程中失去处理器资源。

    运行状态转换为死亡状态：当此线程线程执行体执行完毕或发生了异常。

    此处需要特别注意的是：当调用线程的yield()方法时，线程从运行状态转换为就绪状态，但接下来CPU调度就绪状态中的哪个线程具有一定的随机性，因此，可能会出现A线程调用了yield()方法后，接下来CPU仍然调度了A线程的情况

  • wait/sleep 的区别：主要是对锁的区别

    wait：放开手去睡，放开手里的锁

    sleep：握紧手去睡，醒了手里还有锁

    wait是Object的方法，sleep是thread的方法

  • 进程和线程的关系：

    进程：进程是一个具有一定独立功能的程序关于某个数据集合的一次运行活动。它是操作系统动态执行的基本单元

    **线程：**一个进程中可以包含若干个线程，当然一个进程中至少有一个线程，进程作为分配资源的基本单位，而把线程作为独立运行和独立调度的基本单位

2、并行和并发

  • 并行：多项工作一起执行，之后再汇总。
  • 并发：同一时刻多个线程在访问同一个资源，多个线程对一个点进行操作

3、Synchronized 锁

synchronized实现同步的基础：Java中的每一个对象都可以作为锁。具体表现为以下3种形式：

  1. 对于普通同步方法，锁是当前实例对象。

  2. 对于静态同步方法，锁是当前类的Class对象。

  3. 对于同步方法块，锁是Synchronized 括号里配置的对象

当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。也就是说：

如果一个实例对象的非静态同步方法获取锁后，该实例对象的其他非静态同步方法必须等待获取锁的方法释放锁后才能获取锁；可是不同实例对象的非静态同步方法因为用的是不同对象的锁，所以毋须等待其他实例对象的非静态同步方法释放锁，就可以获取自己的锁。

所有的静态同步方法用的是同一把锁——类对象本身。不管是不是同一个实例对象，只要是一个类的对象，一旦一个静态同步方法获取锁之后，其他对象的静态同步方法，都必须等待该方法释放锁之后，才能获取锁。

而静态同步方法（Class对象锁）与非静态同步方法（实例对象锁）之间是不会有竞态条件的。

4、JUC包的Lock锁

4.1 ReentrantLock可重入锁：

lock.lock() :上锁，lock.unlock():解锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

4.2 公平锁：

锁上等待时间最长的线程将获得锁的使用权。通俗的理解就是谁排队时间最长谁先执行获取锁。

	private ReentrantLock lock = new ReentrantLock(true);//true代表该锁是公平锁

4.3 限时等待：lock.tryLock()

也就是通过我们的tryLock方法来实现，可以选择传入时间参数，表示等待指定的时间，无参则表示立即返回锁申请的结果：true表示获取锁成功，false表示获取锁失败。我们可以将这种方法用来解决死锁问题。

4.4 ReentrantLock和synchronized区别：

（1）synchronized是独占锁，加锁和解锁的过程自动进行，易于操作，但不够灵活。ReentrantLock也是独占锁，加锁和解锁的过程需要手动进行，不易操作，但非常灵活。

（2）synchronized可重入，因为加锁和解锁自动进行，不必担心最后是否释放锁；ReentrantLock也可重入，但加锁和解锁需要手动进行，且次数需一样，否则其他线程无法获得锁。

（3）synchronized不可响应中断，一个线程获取不到锁就一直等着；ReentrantLock可以响应中断。

4.5 ReentrantReadWriteLock 读写锁

  • ReentrantReadWriteLock.Read :读锁，上锁后，其他线程只能读，不能写
  • ReentrantReadWriteLock.Write :写锁，上锁后，其他线程即不能读，也不能写

5、 线程间的通信

5.1 线程虚假唤醒-未满足唤醒条件就进行了唤醒

中断和虚假唤醒是可能产生的，所以要用loop循环，if只判断一次，while是只要唤醒就要拉回来再判断一次。解决方式：不采用if进行唤醒条件的判断，而是使用while进行条件判断。

5.2 线程通信：使用Condition实现线程通信

await():等待 | single()：唤醒 | singalAll(): 唤醒所有
在这里插入图片描述### 6、 并发容器类

6.1 CopyOnWrite容器

CopyOnWrite容器（简称COW容器）即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。它的本质是：数组

6.2 CopyOnWrite作用

CopyOnWrite并发容器用于读多写少的并发场景。比如：白名单，黑名单。假如我们有一个搜索网站，用户在这个网站的搜索框中，输入关键字搜索内容，但是某些关键字不允许被搜索。这些不能被搜索的关键字会被放在一个黑名单当中，黑名单一定周期才会更新一次。

6.3 CopyOnWrite缺点

  1. **内存占用问题。**写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存。通过压缩容器中的元素的方法来减少大对象的内存消耗，比如，如果元素全是10进制的数字，可以考虑把它压缩成36进制或64进制。或者不使用CopyOnWrite容器，而使用其他的并发容器，如ConcurrentHashMap。

  2. **数据实时一致性问题。**CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。

6.4 类对比

  • ArrayList =========> CopyOnWriteArrayList

  • Set ==============> CopyOnWriteArraySet

  • HashMap==========> ConcurrentHashMap

7、JUC 强大的辅助类

7.1 CountDownLatch (倒计数器)

CountDownLatch是一个非常实用的多线程控制工具类，应用非常广泛。

例如：在手机上安装一个应用程序，假如需要5个子进程检查服务授权，那么主进程会维护一个计数器，初始计数就是5。用户每同意一个授权该计数器减1，当计数减为0时，主进程才启动，否则就只有阻塞等待了。

CountDownLatch中count down是倒数的意思，latch则是门闩的含义。整体含义可以理解为倒数的门栓，似乎有一点“三二一，芝麻开门”的感觉。CountDownLatch的作用也是如此。

常用的就下面几个方法：

  • new CountDownLatch(int count) //实例化一个倒计数器，count指定初始计数
  • countDown() // 每调用一次，计数减一
  • await() //等待，当计数减到0时，阻塞线程（可以是一个，也可以是多个）并行执行

面试：CountDownLatch 与 join 方法的区别？

调用一个子线程的 join()方法后，该线程会一直被阻塞直到该线程运行完毕。而 CountDownLatch 则使用计数器允许子线程运行完毕或者运行中时候递减计数，也就是 CountDownLatch 可以在子线程运行任何时候让 await 方法返回而不一定必须等到线程结束；另外使用线程池来管理线程时候一般都是直接添加 Runnable 到线程池这时候就没有办法在调用线程的 join 方法了，countDownLatch 相比 Join 方法让我们对线程同步有更灵活的控制。

7.2 CyclicBarrie (循环栅栏)

从字面上的意思可以知道，这个类的中文意思是“循环栅栏”。大概的意思就是一个可循环利用的屏障。该命令只在每个屏障点运行一次。若在所有参与线程之前更新共享状态，此屏障操作很有用

常用方法：

  1. CyclicBarrier(int parties, Runnable barrierAction) 创建一个CyclicBarrier实例，parties指定参与相互等待的线程数，barrierAction一个可选的Runnable命令，该命令只在每个屏障点运行一次，可以在执行后续业务之前共享状态。该操作由最后一个进入屏障点的线程执行。

  2. CyclicBarrier(int parties) 创建一个CyclicBarrier实例，parties指定参与相互等待的线程数。

  3. await() 该方法被调用时表示当前线程已经到达屏障点，当前线程阻塞进入休眠状态，直到所有线程都到达屏障点，当前线程才会被唤醒。

面试：CyclicBarrier和CountDownLatch的区别？

CountDownLatch的计数器只能使用一次，而CyclicBarrier的计数器可以使用reset()方法重置，可以使用多次，所以CyclicBarrier能够处理更为复杂的场景；CountDownLatch允许一个或多个线程等待一组事件的产生，而CyclicBarrier用于等待其他线程运行到栅栏位置。

7.3 Semaphore（信号量）

Semaphore翻译成字面意思为 信号量，Semaphore可以控制同时访问的线程个数。非常适合需求量大，而资源又很紧张的情况。比如给定一个资源数目有限的资源池，假设资源数目为N，每一个线程均可获取一个资源，但是当资源分配完毕时，后来线程需要阻塞等待，直到前面已持有资源的线程释放资源之后才能继续。

常用方法：

public Semaphore(int permits) // 构造方法，permits指资源数目（信号量）
public void acquire() throws InterruptedException // 占用资源，当一个线程调用acquire操作时，它要么通过成功获取信号量（信号量减1），要么一直等下去，直到有线程释放信号量，或超时。
public void release() // （释放）实际上会将信号量的值加1，然后唤醒等待的线程。

信号量主要用于两个目的：

  1. 多个共享资源的互斥使用。

  2. 用于并发线程数的控制。保护一个关键部分不要一次输入超过N个线程。

8、 Callable接口

8.1 Callable和Runable对比

8.2 Callable 的使用

  1. 创建Callable的实现类，并重写call()方法，该方法为线程执行体，并且该方法有返回值

  2. 创建Callable的实例。

  3. 实例化FutureTask类，参数为Callable接口实现类的对象，FutureTask封装了Callable对象call()方法的返回值

  4. 创建多线程Thread对象来启动线程，参数为FutureTask对象。

  5. 通过FutureTask类的对象的get()方法来获取线程结束后的返回值

8.3 callable 接口和runnable 接口的区别

相同点：都是接口，都可以编写多线程程序，都采用Thread.start()启动线程

不同点：1. 具体方法不同：一个是run，一个是call

  1. Runnable没有返回值；Callable可以返回执行结果，是个泛型

  2. Callable接口的call()方法允许抛出异常；Runnable的run()方法异常只能在内部消化，不能往上继续抛

它提供了检查计算是否完成的方法，以等待计算的完成，并检索计算的结果。

8.4 获取多线程的几种方式

  • 传统的是继承thread类和实现runnable接口，java.lang包下方法

  • java5以后又有实现callable接口和java的线程池获得，JUC 下方法

9 、阻塞队列（BlockingQueue）

9.1什么是BlockingQueue

在多线程领域：所谓阻塞，在某些情况下会挂起线程（即阻塞），一旦条件满足，被挂起的线程又会自动被唤起。

BlockingQueue即阻塞队列，是java.util.concurrent下的一个接口，因此不难理解，BlockingQueue是为了解决多线程中数据高效安全传输而提出的。从阻塞这个词可以看出，在某些情况下对阻塞队列的访问可能会造成阻塞。被阻塞的情况主要有如下两种：

  1. 当队列满了的时候进行入队列操作

  2. 当队列空了的时候进行出队列操作

因此，当一个线程试图对一个已经满了的队列进行入队列操作时，它将会被阻塞，除非有另一个线程做了出队列操作；同样，当一个线程试图对一个空队列进行出队列操作时，它将会被阻塞，除非有另一个线程进行了入队列操作。

阻塞队列主要用在生产者/消费者的场景，下面这幅图展示了一个线程生产、一个线程消费的场景：

在这里插入图片描述
为什么需要BlockingQueue 好处是我们不需要关心什么时候需要阻塞线程，什么时候需要唤醒线程，因为这一切BlockingQueue都给你一手包办了。在concurrent包发布以前，在多线程环境下，我们每个程序员都必须去自己控制这些细节，尤其还要兼顾效率和线程安全，而这会给我们的程序带来不小的复杂度。

9.2 认识BlockingQueue

java.util.concurrent 包里的 BlockingQueue是一个接口，继承Queue接口，Queue接口继承 Collection。

在这里插入图片描述
BlockingQueue接口主要有以下7个实现类：

  1. ArrayBlockingQueue：由数组结构组成的有界阻塞队列。

  2.      LinkedBlockingQueue：由链表结构组成的有界（但大小默认值为integer.MAX_VALUE）阻塞队列。

  3.      PriorityBlockingQueue：支持优先级排序的无界阻塞队列。

  4.      DelayQueue：使用优先级队列实现的延迟无界阻塞队列。

  5. SynchronousQueue：不存储元素的阻塞队列，也即单个元素的队列。

  6.      LinkedTransferQueue：由链表组成的无界阻塞队列。

  7. LinkedBlockingDeque：由链表组成的双向阻塞队列。

BlockingQueue接口有以下几个方法：

在这里插入图片描述
它的方法可以分成以下4类：

抛出异常 特殊值 阻塞 超时
插入 add(e) offer(e) put(e) offer(e, time, unit)
移除 remove() poll() take() poll(time, unit)
检查 element() peek() 不可用 不可用

抛出异常

add正常执行返回true，element（不删除）和remove返回阻塞队列中的第一个元素 当阻塞队列满时，再往队列里add插入元素会抛IllegalStateException:Queue full 当阻塞队列空时，再往队列里remove移除元素会抛NoSuchElementException 当阻塞队列空时，再调用element检查元素会抛出NoSuchElementException

特定值 插入方法，成功ture失败false 移除方法，成功返回出队列的元素，队列里没有就返回null 检查方法，成功返回队列中的元素，没有返回null

一直阻塞

如果试图的操作无法立即执行，该方法调用将会发生阻塞，直到能够执行。 当阻塞队列满时，再往队列里put元素，队列会一直阻塞生产者线程直到put数据or响应中断退出 当阻塞队列空时，再从队列里take元素，队列会一直阻塞消费者线程直到队列可用

超时退出

如果试图的操作无法立即执行，该方法调用将会发生阻塞，直到能够执行，但等待时间不会超过给定值。 返回一个特定值以告知该操作是否成功(典型的是 true / false)。

10、ThreadPool线程池

10.1 为什么使用线程池

线程池的优势： 线程池做的工作主要是控制运行的线程数量，处理过程中将任务放入队列，然后在线程创建后启动这些任务，如果线程数量超过了最大数量，超出数量的线程排队等候，等其他线程执行完毕，再从队列中取出任务来执行。

它的主要特点为：线程复用；控制最大并发数；管理线程。

  1. 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的销耗。

  2. 提高响应速度。当任务到达时，任务可以不需要等待线程创建就能立即执行。

  3. 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会销耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

10.2 创建线程池的7个重要参数

在这里插入图片描述

  1. corePoolSize：线程池中的常驻核心线程数

  2. maximumPoolSize：线程池中能够容纳同时 执行的最大线程数，此值必须大于等于1

  3. keepAliveTime：多余的空闲线程的存活时间 当前池中线程数量超过corePoolSize时，当空闲时间达到keepAliveTime时，多余线程会被销毁直到 只剩下corePoolSize个线程为止

  4. unit：keepAliveTime的单位

  5. workQueue：任务队列，被提交但尚未被执行的任务

  6. threadFactory：表示生成线程池中工作线程的线程工厂， 用于创建线程，一般默认的即可

  7. handler：拒绝策略，表示当队列满了，并且工作线程大于 等于线程池的最大线程数（maximumPoolSize）时，如何来拒绝 请求执行的runnable的策略

  • 注：在实际工作中，我们通常自定义线程池，从不使用提供创建线程池的工具类：Executors（太拉了）

10.3 线程池底层工作原理

具体流程：
在这里插入图片描述
重要的事情说三遍：以下重要：以下重要：以下重要：

  1. 在创建了线程池后，线程池中的线程数为零。

  2. 当调用execute()方法添加一个请求任务时，线程池会做出如下判断：

    1. 如果正在运行的线程数量小于corePoolSize，那么马上创建线程运行这个任务；
    2. 如果正在运行的线程数量大于或等于corePoolSize，那么将这个任务放入队列；
    3. 如果这个时候队列满了且正在运行的线程数量还小于maximumPoolSize，那么还是要创建非核心线程立刻运行队列中的任务；
    4. 如果队列满了且正在运行的线程数量大于或等于maximumPoolSize，那么线程池会启动饱和拒绝策略来执行。

  3. 当一个线程完成任务时，它会从队列中取下一个任务来执行。

  4. 当一个线程无事可做超过一定的时间（keepAliveTime）时，线程会判断：

​ 如果当前运行的线程数大于corePoolSize，那么这个线程就被停掉。

​ 所以线程池的所有任务完成后，它最终会收缩到corePoolSize的大小。

10.4 线程池的拒绝策略

一般我们创建线程池时，为防止资源被耗尽，任务队列都会选择创建有界任务队列，但这种模式下如果出现任务队列已满且线程池创建的线程数达到你设置的最大线程数时，这时就需要你指定ThreadPoolExecutor的RejectedExecutionHandler参数即合理的拒绝策略，来处理线程池”超载”的情况。

ThreadPoolExecutor自带的拒绝策略如下：

  • AbortPolicy(默认)：直接抛出RejectedExecutionException异常阻止系统正常运行

  • CallerRunsPolicy：“调用者运行”一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量。

  • DiscardOldestPolicy：抛弃队列中等待最久的任务，然后把当前任务加人队列中 尝试再次提交当前任务。

  • DiscardPolicy：该策略默默地丢弃无法处理的任务，不予任何处理也不抛出异常。 如果允许任务丢失，这是最好的一种策略。

以上内置的策略均实现了RejectedExecutionHandler接口，也可以自己扩展RejectedExecutionHandler接口，定义自己的拒绝策略

11、 多线程高并发底层原理

11.1 锁类型的分离

锁的分离（强调由低到高） 描述
乐观锁 默认无其他线程修改过，本线程修改时比较版本，版本相同，进行修改。 底层CAS
自旋锁 底层 do while (!CAS)
悲观锁 可重入锁、默认资源都会被其他线程修改 底层AQS =CAS+volatile state
独占-互斥锁 不可重入：Mutex api 使用案例

11.2 java内存模型（JMM）

JMM即为JAVA 内存模型（java memory model）。因为在不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，结果就是当你的代码在某个系统环境下运行良好，并且线程安全，但是换了个系统就出现各种问题。Java内存模型，就是为了屏蔽系统和硬件的差异，让一套代码在不同平台下能到达相同的访问结果。JMM从java 5开始的JSR-133发布后，已经成熟和完善起来。
在这里插入图片描述
JMM规定了内存主要划分为主内存和工作内存两种。此处的主内存和工作内存跟JVM内存划分（堆、栈、方法区）是在不同的维度上进行的，如果非要对应起来，主内存对应的是Java堆中的对象实例部分，工作内存对应的是栈中的部分区域，从更底层的来说，主内存对应的是硬件的物理内存，工作内存对应的是寄存器和高速缓存。

内存模型的三大特性：

• 原子性：即不可分割性。比如 a=0；（a非long和double类型） 这个操作是不可分割的，那么我们说这个操作时原子操作。再比如：a++； 这个操作实际是a = a + 1；是可分割的，所以他不是一个原子操作。非原子操作都会存在线程安全问题，需要使用同步技术（sychronized）或者锁（Lock）来让它变成一个原子操作。一个操作是原子操作，那么我们称它具有原子性。java的concurrent包下提供了一些原子类，我们可以通过阅读API来了解这些原子类的用法。比如：AtomicInteger、AtomicLong、AtomicReference等。

• **可见性：**每个线程都有自己的工作内存，所以当某个线程修改完某个变量之后，在其他的线程中，未必能观察到该变量已经被修改。**在 Java 中 volatile、synchronized 和 final 实现可见性。**volatile只能让被他修饰内容具有可见性，但不能保证它具有原子性。

• **有序性：**java的有序性跟线程相关。一个线程内部所有操作都是有序的，如果是多个线程所有操作都是无序的。因为JMM的工作内存和主内存之间存在延迟，而且java会对一些指令进行重新排序。volatile和synchronized可以保证程序的有序性，很多程序员只理解这两个关键字的执行互斥，而没有很好的理解到volatile和synchronized也能保证指令不进行重排序。

11.3 volatile 关键字

1、作用：将线程中CPU的内部内存缓存同步到主内存中，确保其他线程能够访问到被其他线程修改过的volatile 修饰的资源数据。

2、原理：Java语言提供了一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器（工作内存）或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。JMM 内存模型

在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比sychronized关键字更轻量级的同步机制。

当一个变量定义为 volatile 之后，将具备两种特性：

• 保证此变量对所有的线程的可见性。

• 不保证变量的原子性

3、volatile 性能：volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。

11.4 CAS：乐观自旋锁

CAS：Compare and Swap。比较并交换的意思。CAS操作有3个基本参数：内存地址A，旧值B，新值C。它的作用是将指定内存地址A的内容与所给的旧值B相比，如果相等，则将其内容替换为指令中提供的新值C；如果不等，则更新失败。类似于修改登陆密码的过程。当用户输入的原密码和数据库中存储的原密码相同，才可以将原密码更新为新密码，否则就不能更新。

**CAS是解决多线程并发安全问题的一种乐观锁算法。**因为它在对共享变量更新之前，会先比较当前值是否与更新前的值一致，如果一致则更新，如果不一致则循环执行（称为自旋锁），直到当前值与更新前的值一致为止，才执行更新。

Unsafe类是CAS的核心类，提供硬件级别的原子操作（目前所有CPU基本都支持硬件级别的CAS操作）。

// 对象、对象的地址、预期值、修改值
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

CAS 的缺点：

  • 开销大：在并发量比较高的情况下，如果反复尝试更新某个变量，却又一直更新不成功，会给CPU带来较大的压力
  • ABA问题：当变量从A修改为B在修改回A时，变量值等于期望值A，但是无法判断是否修改，CAS操作在ABA修改后依然成功。
  • 不能保证代码块的原子性：CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。

11.4 AQS 抽象队列同步器AbstractQueuedSynchronizer

11.4.1 框架结构

AQS框架结构如下：

在这里插入图片描述
新来的线程先尝试上锁操作，没有拿到锁。准备到队列中排队，但排队前才尝试拿一次锁。

11.4.2 可重入锁底层
  • 上锁操作

在这里插入图片描述
AQS维护了一个volatile语义(支持多线程下的可见性)的共享资源变量state和一个FIFO（first-in-first-out）线程等待队列(多线程竞争state资源被阻塞时，会进入此队列)。
在这里插入图片描述
可重入锁的代码判断—If：判断当前线程是不是已经持有锁的进程。

11.4.3 基于AQS实现锁的思路

AQS将大部分的同步逻辑均已经实现好，继承的自定义同步器只需要实现state的获取(acquire)和释放(release)的逻辑代码就可以，主要包括下面方法：

• tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。

• tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。

• tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。

• tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

• isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。

也就是说：

通过AQS可以实现独占锁（只有一个线程可以获取到锁，如：ReentrantLock），也可以实现共享锁（多个线程都可以获取到锁Semaphore/CountDownLatch等）

11.4.4 基于AQS 实现独占锁

直接将jdk 文档中的案例改写成自己的独占锁代码，官方文档地址位置：
在这里插入图片描述

11.5 ReentrantLock底层原理

接下来就以ReetrantLock为例，说明AQS在锁底层的应用。
在这里插入图片描述
在ReentrantLock类中包含了3个AQS的实现类：

  1. 抽象类Sync

  2.     非公平锁实现类NonfaireSync

  3.     公平锁实现类FairSync

在ReetrantLock的源码中可以发现：
在这里插入图片描述

11.5.1. Sync抽象类

内部方法主要包括：

/**
  * 自定义方法：为非公平锁的实现提供快捷路径
  */
 abstract void lock();
 
 /**
  * 自定义通用方法，两个子类的tryAcquire方法都需要使用非公平的trylock方法
  */
 final boolean nonfairTryAcquire(int acquires) {
     final Thread current = Thread.currentThread();
     int c = getState();
     if (c == 0) { // 如果当前线程没有获取到锁
         if (compareAndSetState(0, acquires)) { // 则CAS获取锁
             setExclusiveOwnerThread(current); // 并把当前线程设置为拥有排他访问权限
             return true;
         }
     }
     else if (current == getExclusiveOwnerThread()) { // 如果当前线程已经拥有锁，则重入
         int nextc = c + acquires; // 每重入一次stat累加acquires
         if (nextc < 0) // overflow
             throw new Error("Maximum lock count exceeded");
         setState(nextc);
         return true;
     }
     return false;
 }
 
 /**
  * 实现AQS的释放锁方法
  */
 protected final boolean tryRelease(int releases) {
     int c = getState() - releases; // 每释放一次stat就减releases
     if (Thread.currentThread() != getExclusiveOwnerThread()) // 当前线程不是有锁线程抛异常
         throw new IllegalMonitorStateException();
     boolean free = false;
     if (c == 0) { // stat减为0则释放锁
         free = true;
         setExclusiveOwnerThread(null);
     }
     setState(c);
     return free;
 }
 
 protected final boolean isHeldExclusively() {
     // While we must in general read state before owner,
     // we don't need to do so to check if current thread is owner
     return getExclusiveOwnerThread() == Thread.currentThread();
 }

9.4.4.2. NonfairSync

/**
  * Sync object for non-fair locks
  */
 static final class NonfairSync extends Sync {
     private static final long serialVersionUID = 7316153563782823691L;
 
     /**
      * Performs lock.  Try immediate barge, backing up to normal
      * acquire on failure.
      */
     final void lock() {
         if (compareAndSetState(0, 1)) // CAS把stat设置为1
             setExclusiveOwnerThread(Thread.currentThread()); // 获取到锁
         else
             acquire(1); 
     }
 
     protected final boolean tryAcquire(int acquires) {
         return nonfairTryAcquire(acquires); // 使用了Sync抽象类的nonfairTryAcquire方法
     }
 }

acquire(1)方法是AQS自己实现的本质就是调用tryAcquire方法，如果tryAcquire获取到锁并无法进入等待队列则中止线程。
在这里插入图片描述

9.4.4.3. FairSync

/**
  * Sync object for fair locks
  */
 static final class FairSync extends Sync {
     private static final long serialVersionUID = -3000897897090466540L;
 
     final void lock() {
         acquire(1);
     }
 
     /**
      * Fair version of tryAcquire.  Don't grant access unless
      * recursive call or no waiters or is first.
      */
     protected final boolean tryAcquire(int acquires) {
         final Thread current = Thread.currentThread();
         int c = getState();
         if (c == 0) {
             if (!hasQueuedPredecessors() &&  // 从线程有序等待队列中获取等待
                 compareAndSetState(0, acquires)) { 
                 setExclusiveOwnerThread(current);
                 return true;
             }
         }
         else if (current == getExclusiveOwnerThread()) { // 可重入
             int nextc = c + acquires;
             if (nextc < 0)
                 throw new Error("Maximum lock count exceeded");
             setState(nextc);
             return true;
         }
         return false;
     }
 }

hasQueuedPredecessors具体实现如下：
在这里插入图片描述

  1. 当等待队列中只有一个线程时，直接获取到锁

  2. 如果队列不止一个线程，但下一个线程就是当前申请锁的线程，则获取锁

版权声明：本文为m0_46499246原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/m0_46499246/article/details/115332550