【javaEE】——多线程进阶（锁策略：面试相关考点）04

目录

一、常见的锁策略

1.1乐观锁 vs 悲观锁

1.2 读写锁

1.3重量级锁 vs 轻量级锁

1.4挂起等待锁和自旋锁

1.5公平锁 和非公平锁 

1.6可重入锁 和 不可重入锁

二、CAS（Compare and swap）比较并交换

2.1CAS的实现

2.2 CAS中的ABA问题

三、Synchronized 原理

3.1加锁过程

3.2 锁的其他优化（锁的粒度）

3.3 Callable 接口

3.4 ReentrantLock 可重入互斥锁.

四、信号量Semaphore

五、CountDownLatch倒计时的锁存器

六、线程安全的集合类

6.1多线程环境使用 ArrayList

6.2 多线程环境使用队列

6.3 多线程环境使用哈希表

一、常见的锁策略

锁策略不局限于 Java . 任何和 "锁" 相关的话题, 都可能会涉及到以下内容. 这些特性主要是给锁的实现者来参考的.普通的程序猿也需要了解一些, 对于合理的使用锁也是有很大帮助的.

1.1乐观锁 vs 悲观锁

悲观锁（重量级锁）： 假设冲突概率高甚至每次加锁都会冲突（总是假设出现坏情况）

乐观锁（轻量级锁）：假设冲突概率高甚至每次加锁都会冲突，发现冲突才去解决；引入版本号：提交版本号>当前版本号（线程内版本号>内存中版本号）

小数据量可考虑乐观锁，Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略.

1.2 读写锁

多线程之间，数据的读取方之间不会产生线程安全问题，但数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁，就会产生极大的性能损耗。

synchronized对读写没有区分，如果读写都有，使用就会互斥

一个线程对于数据的访问, 主要存在两种操作: 读数据、 写数据.

• 两个线程都只是读一个数据，没有线程安全问题. 直接并发的读取即可.（读锁不互斥）
• 两个线程都要写一个数据, 有线程安全问题.（写锁互斥）
• 一个线程读另外一个线程写, 也有线程安全问题.（读写互斥）

1.3重量级锁 vs 轻量级锁

锁的核心特性 "原子性", 追根溯源是 CPU 这样的硬件设备提供的：

• CPU 提供了 "原子操作指令".
• 操作系统基于 CPU 的原子指令, 实现了 mutex 互斥锁.
• JVM 基于操作系统提供的互斥锁, 实现了 synchronized 和 ReentrantLock 等关键字和类.

悲观锁乐观锁描述的是应用场景，看锁冲不冲突；

重量级锁 和轻量级锁 与 应用场景  没啥关系，主要看  开销

重量级锁：重度依赖了 OS 提供了 mutex接口。加锁开销较大，往往在内核态完成，易引发线程调度
轻量级锁：尽可能不使用 mutex接口, 尽量在用户态代码完成， 再使用 mutex.加锁开销较小，往往在用户态完成。（少量的内核态用户态切换），用户态的代码更可控，更高效

1.4挂起等待锁和自旋锁

自旋锁、挂起等待锁，都是在synchronized内置的。

1.自旋锁： 线程获取不到锁，会再快速再试一次，节省了OS调度线程的开销，比挂起等待锁能更及时获取到锁（用户态实现，轻量级锁），没有放弃 CPU, 不涉及线程阻塞和调度, 一旦锁被释放, 就能第一时间获取到锁.

2.挂起等待锁：获取不到锁就会阻塞等待，（啥时结束阻塞）取决于OS调度   --->线程挂起时，不占CPU（一般基于内核态的机制实现，较重），重量级锁

synchronized 中的轻量级锁策略大概率就是通过自旋锁的方式实现的.

1.5公平锁 和非公平锁 

公平锁： 遵守 "先来后到". B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁.
非公平锁：不遵守 "先来后到". B 和 C 都有可能获取到锁.（抢占式执行）

实时操作系统：vxworks(凤河公司)线程调度可控；Windows、Linux：线程调度不可控

适用场合：
大部分情况使用---》非公平锁
期望线程调度的时间成本可控时，---》公平锁

操作系统内部的线程调度就可以视为是随机的. 如果不做任何额外的限制, 锁就是非公平锁；

实现公平锁, 就需要依赖额外的数据结构, 来记录线程们的先后顺序.

1.6可重入锁 和 不可重入锁

可重入锁：“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。

比如一个递归函数里有加锁操作，递归过程中这个锁不会阻塞自己（可重入锁、递归锁）

Java里只要以Reentrant开头命名的锁都是可重入锁，而且JDK提供的所有现成的Lock实现类，包括synchronized关键字锁都是可重入的。 Linux 系统提供的 mutex 是不可重入锁.

synchronized锁策略：

• 即是悲观锁也是乐观锁（根据锁竞争的激烈程度自适应）
• 不是读写锁，只是普通的互斥锁
• 既是轻量锁，也是重量锁（根据锁竞争的激烈程度自适应）
• 轻量级锁的实现基于自旋锁，重量级锁部分基于挂起等待锁来实现
• 非公平锁
• 可重入锁

二、CAS（Compare and swap）比较并交换

 当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但并不会阻塞其他线程，其他线程只会收到操作失败的信号。

CAS 可以视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式)，CAS也是多线程安全的一种实现手段。

2.1CAS的实现

假设内存中的原数据V，旧的预期值A，需要修改的新值B。
1. 比较 A 与 V 是否相等。（比较）
2. 如果比较相等，将 B 写入 V。（交换）
3. 返回操作是否成功。

比较  两个内存   或者  寄存器和内存，操作是原子的。

 伪代码（逻辑理解）：

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

一条单独的CAS指令即可完成这个逻辑

（1）CAS 的实现

针对不同的操作系统，JVM 用到了不同的 CAS 实现原理：

• java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作；
• unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg；
• Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。

（2）CAS的应用

• 1）实现原子类

标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现的.针对常用数据类型进行了疯涨，可基于CAS（不涉及线程等待）进行修改，并且线程安全（Atomic原子的）

• CAS 是直接读写内存的, 而不是操作寄存器.
• CAS 的读内存, 比较, 写内存操作是一条硬件指令, 是原子的.

import java.util.concurrent.atomic.AtomicInteger;public class suoDemo {public static void main(String[] args) throws InterruptedException {AtomicInteger num = new AtomicInteger(0);Thread t = new Thread(() ->{for (int i = 0; i <5000; i++) {num.getAndIncrement(); //num自增}});Thread t2 = new Thread(() ->{for (int i = 0; i <5000; i++) {num.getAndIncrement();}});t.start();t2.start();t.join();t2.join();}
}


CAS操作步骤：

1. 相等则直接赋值
2. 不等则进入循环，重新读取内存中的值，再次进行比较，然后再赋值
3. 各自线程返回交换前的数值

• 2）实现自旋锁

伪代码实现：

CAS由CPU指令一次性完成比较和交换的过程，不加锁也可保证线程安全

若当前锁this.owner=null,则设置this.owner=Thread.currentThread()

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

2.2 CAS中的ABA问题

ABA 的问题:
假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A。线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要：

• 先读取 num 的值, 记录到 oldNum 变量中.
• 使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z。

但是, 在 t1 执行这两个操作之间, t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A（ABA 问题引来的 BUG）

ABA问题如何解决？？？

数据从A-->B -->A：
引入版本号是否一致，一致才替换（乐观锁机制），修改变量的时候比较的是版本号

给要修改的数据引入版本号。 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期。当前版本号和之前读到的版本号一致, 就执行修改操作, 并让版本号自增； 如果发现当前版本号比之前读到的版本号大, 就认为操作失败

三、Synchronized 原理

3.1加锁过程

JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况，进行依次升级。

（1）偏向锁

第一个尝试加锁的线程, 优先进入偏向锁状态（给对象头中做一个 "偏向锁的标记"，记录锁属于哪个线程.）。

• 若后续无其他线程来竞争该锁，就不用进行其他同步操作了(避免了加锁解锁的开销)
• 若后续有其他线程来竞争该锁（锁对象中记录了当前锁属于哪个线程， 很容易识别当前申请锁的线程是不是之前记录的线程），那就取消原来的偏向锁状态, 进入一般的轻量级锁状态.

偏向锁本质：相当于 "延迟加锁" . 能不加锁就不加锁, 尽量来避免不必要的加锁开销。但是该做的标记还是得做的, 否则无法区分何时需要真正加锁.（延时加锁，提前先设置一个标记，无冲突则不加锁；有冲突时再加锁-->变为轻量级锁（基于CAS的自旋锁，用户态完成不涉及内核态切换和阻塞，会耗费CPU））

（2）轻量级锁

其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态（CAS实现，自适应的自旋锁)：

• 通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
• 如果更新成功, 则认为加锁成功
• 如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU)（自旋操作一直让 CPU 空转, 比较浪费 CPU 资源。因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋）

（3) 重量级锁
若竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁。重量级锁就是指用到内核提供的 mutex接口：

• 执行加锁操作, 先进入内核态.
• 在内核态判定当前锁是否已经被占用
• 如果该锁没有占用, 则加锁成功, 并切换回用户态.
• 如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒.
• 经历了一系列后，锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁.

3.2 锁的其他优化（锁的粒度）

编译器和JVM自行判断是否需要加锁（不需要时取消锁，需要时加锁）

一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化.

锁的粒度：synchronized包含的代码多少：

• 多：锁的粒度粗，无其他线程竞争锁，避免频繁释放锁，直接粗化（一次加锁，完成多个任务）
• 少：锁的粒度细，持锁时间短，能很快释放，冲突概率小

实际开发过程中, 使用细粒度锁, 是期望释放锁时，其他线程能使用锁。但是实际上，可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化, 避免频繁申请释放锁.

3.3 Callable 接口

Callable 是一个 interface . 相当于把线程封装了一个 "返回值".

代码示例: 创建线程计算 1 + 2 + 3 + ... + 1000：

• 创建一个匿名内部类, 实现 Callable （ 带泛型参数（返回值类型））接口
• 重写 Callable 的 call 方法, 完成累加的过程（任务的执行）
• 把 callable 实例使用 FutureTask 包装一下（辅助类）
• 创建线程, 线程的构造方法传入 FutureTask . 此时新线程就会执行 FutureTask 内部的 Callable 的call 方法, 完成计算. 计算结果就放到了 FutureTask 对象中.
• 在主线程中调用 futureTask.get() 能够阻塞等待新线程计算完毕. 并获取到 FutureTask 中的结果.

import java.util.concurrent.Callable;
import java.util.concurrent.FutureTask;public class classDemo2 {public static void main(String[] args) {Callable callable = new Callable() { //通过callable描述任务@Overridepublic Integer call() throws Exception {int sum = 0;for (int i = 0; i <1000; i++) {sum += i;}return sum;}};FutureTask task = new FutureTask<>(callable); //使用中间类FutureTask辅助线程执行任务Thread t = new Thread(task); //创建线程为了完成此处的计算工作t.start();}
}


Callable 和 Runnable 的区别：

•  Callable 描述带有返回值的任务；Runnable 描述不带返回值的任务.
• Callable 通常搭配 FutureTask （保存 Callable 的返回结果）来使用；Callable 往往是在另一个线程中执行的, 什么时候执行完并不确定.
• FutureTask 就可以负责这个等待结果出来的工作.

3.4 ReentrantLock 可重入互斥锁.

可重入互斥锁，是对synchronized的补充，保证线程安全，分开了加锁、解锁，也是用来实现互斥效果。ReentrantLock 的用法:

• lock()：加锁, 如果获取不到锁就死等.
• trylock（超时时间）：加锁,  等待一定的时间之后获取不到就放弃加锁.（尝试加锁失败，直接返回失败，不会阻塞）
• unlock(): 解锁

ReentrantLock和synchronized的区别：

• 1.synchronized 是一个关键字, 是 JVM 内部实现的( C++ )； ReentrantLock 是标准库的一个类, 在 JVM 外实现的( Java ).
• 2.synchronized 不需要手动释放锁，出了代码块锁自然释放； ReentrantLock 使用时需要手动释放，使用起来更灵活,但是也容易遗漏 unlock.
• 3.synchronized在申请锁失败时, 会死等； ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.
• 4.synchronized:  非公平锁；ReentrantLock:  支持公平 和 非公平锁，且提供更强大的唤醒机制（Condition类）--->显式指定唤醒哪个线程
• 5. synchronized 是通过 Object 的 wait / notify 实现等待-唤醒.唤醒的是随机等待的线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 更精确控制唤醒某个指定线程.

如何选择？？？

• 锁竞争不激烈： 使用 synchronized, 效率更高, 自动释放更方便.
• 锁竞争激烈：使用 ReentrantLock, 搭配 trylock 更灵活控制加锁的行为, 而不是死等.
• 如果需要使用公平锁, 使用 ReentrantLock.

四、信号量Semaphore

信号量：表示 "可用资源的个数". 本质上是一个计数器。锁为一个”二元信号量“，可用资源就一个，计数器取值（非0即1）

信号量的 P 操作：申请资源，计数器 -1 （acquire）

信号量的 V 操作：释放资源，计数器 +1   （release）

当计数器为0时，在申请资源就会出现阻塞等待

Semaphore 的 PV 操作中的加减计数器操作都是原子的, 可以在多线程环境下直接使用.

import java.util.concurrent.Semaphore;public class classDemo3 {public static void main(String[] args) throws InterruptedException {Semaphore semaphore = new Semaphore(4); //初始化表示可用资源4个semaphore.acquire(); //申请资源P操作System.out.println("申请成功");semaphore.acquire();System.out.println("申请成功");semaphore.acquire();System.out.println("申请成功");semaphore.acquire();System.out.println("申请成功");
// semaphore.acquire(); // 资源申请完毕，触发acquire等待机制
// System.out.println("申请成功");semaphore.release();System.out.println("释放资源");}
}


五、CountDownLatch倒计时的锁存器

同时等待 N 个任务执行结束，待所有任务的线程执行完毕，主线程调用latch.await()

• 构造 CountDownLatch 实例, 初始化 10 表示有 10 个任务需要完成.
• 每个任务执行完毕, 都调用 latch.countDown() . 在 CountDownLatch 内部的计数器同时自减.
• 主线程中使用 latch.await(); 阻塞等待所有任务执行完毕. 相当于计数器为 0 了.

import java.util.concurrent.CountDownLatch;public class classDemo4 {public static void main(String[] args) throws InterruptedException {CountDownLatch latch = new CountDownLatch(10); // CountDownLatch(10)是构造方法，10表示任务个数for (int i = 0; i <10; i++) {Thread t1 = new Thread(() ->{try {Thread.sleep(1000);System.out.println(Thread.currentThread().getName() + "到达终点!");latch.countDown();} catch (InterruptedException e) {e.printStackTrace();}});t1.start();}latch.await(); //线程未执行完毕，await就阻塞，直至所有线程执行完毕，await才返回}
}


六、线程安全的集合类

6.1多线程环境使用 ArrayList

1) 使用同步机制 (synchronized 或者 ReentrantLock)

2) Collections.synchronizedList(new ArrayList);

• synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的 List.
• synchronizedList 的关键操作上都带有 synchronized

3) 使用 CopyOnWriteArrayList（写时拷贝：修改的时候会创建一个副本出来）双缓冲区策略

• 修改文件时，创建一个副本对其进行修改，若在修改的同时又有读取操作，则先读取原文件的内容（非副本），当修改完毕后，源文件的引用指向副本（副本替换原文件）

对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器是一种读写分离的思想，读和写不同的容器。

6.2 多线程环境使用队列

1) ArrayBlockingQueue：基于数组实现的阻塞队列
2) LinkedBlockingQueue：基于链表实现的阻塞队列
3) PriorityBlockingQueue：基于堆实现的带优先级的阻塞队列
4) TransferQueue：最多只包含一个元素的阻塞队列

6.3 多线程环境使用哈希表

HashMap 是线程不安全的。在多线程环境下使用哈希表可以使用:

• Hashtable【不推荐使用】
• ConcurrentHashMap

ConcurrentHashMap锁对象：针对每个元素（哈希桶）

（1）Hashtable

简单的给方法加锁（针对this加锁），会导致锁竞争加大，效率降低.直接针对 Hashtable 对象本身加锁

• 一个HashTable只有一把锁，任意两个或多个都会出现锁竞争/冲突。
• size 属性也是通过 synchronized 来控制同步, 比较慢
• 一旦触发扩容, 就由该线程完成整个扩容过程（涉及到大量的元素拷贝, 效率会非常低）

 （2）ConcurrentHashMap

相较于Hashtable使用粒度更小的锁，对每个元素象进行加锁，降低了锁冲突的概率。

• 读操作不加锁，只使用，只针对写操作加锁。
• 减少了所冲突，不锁整个对象, 而是 "锁桶”（让锁加到每个对象的链表头节点上）
• 更广泛使用 CAS 特性，提升效率（如维护 size操作， 避免出现重量级锁的情况）
• 优化扩容方式：化整为零（1个锁变为多个锁）
  • 触发了扩容机制，每次只是搬运一点点，通过多次完成整个搬运过程。
  • 搬完最后一个元素再把老数组删掉；这个期间, 插入只往新数组加.这个期间, 查找需要同时查新数组和老数组