qidao123.com技术社区-IT企服评测·应用市场

标题: 【JavaEE -- 多线程进阶 - 面试重点】 [打印本页]

---

作者: 来自云龙湖轮廓分明的月亮    时间: 2025-5-12 01:58
标题: 【JavaEE -- 多线程进阶 - 面试重点】
1. 常见锁战略

加锁过程中，处理冲突的过程中，涉及到一些差别的处理方式。
1.1 乐观锁和悲观锁

• 乐观锁：在加锁之前，预估当前出现锁冲突的概率不大，因此在举行加锁的时间就不会做太多的工作，加锁的过程中做的事情比较少，加锁的速度比较快，但是更容易引入一些其他的题目，可能会消耗更多的cpu资源。
  
• 悲观锁：在加锁之前，预估当前锁冲突出现的概率比较大，因此在加锁的时间做更多的工作，做的事情更多，加锁的速度可能更慢，但是整个过程中不容易出现其他题目。
  
• 乐观锁的实现：引入一个版本号，借助版本号识别出当前的数据访问是否冲突。
  
• 悲观锁的实现：先加锁（比如借助操作系统提供的mutex），获取到锁再操作数据，获取不到就等待。
  

1.2 轻量级锁和重量级锁

按加锁开销的大小分：

• 轻量级锁：加锁的开销小，加锁的速度更快，轻量级锁一般就乐观锁。
  
• 重量级锁：加锁的开销大，加锁的速度更慢，重量级锁一般是悲观锁。
  

轻量和重量是加锁之后对结果的评价，乐观和悲观是加锁之前，对未发生的事情举行的预估，整体来说，这两种角度描述的是同一个事情。
1.3 自旋锁和挂起等待锁

• 自旋锁：是轻量级锁的一种典型实现，举行加锁的时间，搭配一个while循环，假如加锁乐成，自然循环竣事。假如加锁不乐成，不是阻塞放弃cpu，而是举行下一次循环，再次尝试获取到锁。这个反复快速执行的过程就称为自旋。一旦其他线程开释了锁，就能第一时间拿到锁。同时这样的自旋锁也就是乐观锁。自旋的条件：就是预期冲突的概率不大，其他线程开释了锁，就能第一时间拿到锁。当加锁的线程很多，自旋的意义就不大了，会浪费CPU资源。
  
• 挂起等待锁：重量级锁的一种典型实现，举行等待挂起等待的时间，就必要内核调度器介入，这一块要完成的操作很多，真正获取到锁花的时间就更多。同时也是一种悲观锁，这个锁可以适用于锁冲突激烈的情况。
  

synchronized具有自顺应能力

• 假如当前锁冲突的激烈程度不大，就处于乐观锁/轻量级锁/自旋锁。
  
• 假如当前锁冲突的激烈程度很大，就处于悲观锁/重量级锁/挂起等待锁。
  

1.4 普通互斥锁和读写锁

一个线程对于数据的访问，主要存在两种操作：读数据和写数据。

• 两个线程都只是读一个数据，此时并没有线程安全题目，之间并发的读取即可。
  
• 两个线程都要写一个数据，有线程安全题目。
  
• 一个线程读别的一个线程写，有线程安全题目。
  

• 普通互斥锁：多线程之间，数据的读取时之间不会产生线程安全题目，但是数据的写入方互相之间以及和读者之间都必要举行互斥。假如两种场景下都用同一个锁，就会产生极大的性能消耗，所以引出读写锁。
  
• 读写锁：在执行加锁操作时必要额外表明读写意图，复数读者之间并不互斥，而写者则要求与任何人互斥。读写锁分为两种情况，加 读锁和加 写锁。
  

• 读锁和读锁之间，不会出现锁冲突（不会阻塞，即不互斥）。
  
• 写锁和写锁之间，会出现锁冲突（会阻塞，即互斥）。
  
• 读锁和写锁之间，会出现锁冲突（会阻塞，即互斥）。
  

一个线程加 读锁的时间，另一个线程只能读，不能写。一个线程加 写锁的时间，另一个线程，不能读也不能写。
1.5 公平锁和非公平锁

假如三个线程A，B，C，A先尝试获取锁，获取乐成，然后B再尝试获取锁，获取失败，阻塞等待；然后C也尝试获取锁，C也获取失败，阻塞等待。

• 公平锁：遵守 “先来后到”，当A开释锁，B先于C拿到锁。
  
• 非公平锁：B和C都有可能获取到锁。
  Java中synchronized黑白公平锁。
  

1.6 可重入锁和不可重入锁

• 可重入锁：一个线程针对一把锁，一连两次加锁，不会死锁。synchronized是可重入锁，实现方式：在加锁中记载锁持有的线程身份，以及一个计数器（记载加锁次数），假如发现加锁的线程就是持有锁的线程，则直接计数自增。
  
• 不可重入锁：一个线程针对一把锁，一连两次加锁，会死锁。系统自带的锁是不可重入的锁。
  

2. Synchronized原理（特点、加锁过程、自顺应）

2.1 Synchronized基本特点

• 开始是乐观锁，假如锁冲突频仍，转换为悲观锁（自顺应）
  
• 开始是轻量级锁实现，假如锁被持有的时间较长，就转换为重量级锁（自顺应）
  
• 实现轻量级锁的时间大概率用到自旋锁战略（自顺应）
  
• 是一种不公平锁
  
• 是一种可重入锁
  
• 不是读写锁
  

2.2 Synchronized加锁过程

当线程执行到Synchronized的时间，假如这个对象当前处于为加锁的状态，就会履历以下过程：

• 偏向锁阶段：假设没有线程竞争。 核心头脑就是懒汉模式，能不加锁就不加锁，能晚加锁就晚加锁。所谓的偏向锁，并非真的加锁了，而只是做了一个非常轻量的标记。非须要不加锁，在遇到竞争的情况下，偏向锁没有进步效率，但假如实在没有竞争的情况下，偏向锁就大幅度进步了效率。
  
• 轻量级锁阶段：假设有竞争，但是不多。此处就是通过自旋锁的方式来实现的；优势：别的的线程把锁开释了，就会第一时间拿到锁。劣势：比较消耗cpu，即对于自旋锁来说，假如同一个锁竞争者很多，大量线程都在自旋，整体cpu的消耗就很大。此同时，synchronized内部会统计当前这个锁对象上，有多少个线程在参与竞争，当参与竞争的线程多了就会进一步升级到重量级锁。
  
• 重量级锁阶段：锁竞争进一步激烈，此处的重量级锁就是指用到内核提供的mutex，此时拿不到锁的线程就不会继续自旋了，而是进入阻塞等待，让出cpu，当当前线程开释锁的时间，就由系统随机唤醒一个来获取锁。
  

2.3 锁消除

锁消除也是synchronized中内置的优化战略。编译器优化的一种方式，编译器编译代码的时间，假如发现这个代码，不必要加锁，就会自动把锁给干掉。针对一眼看上去就不涉及安全题目的代码，可以或许把锁消除掉，对于其他的很多含糊其词的，都不会消除。
2.4 锁粗化

锁粗化，会把多个细粒度的锁，合并成一个粗粒度的锁。粒度指的是synchronized {}里大括号里面包含代码越少，就认为锁的粒度越细，包含的代码越多，就认为锁的粒度越粗。
通常情况下，是更偏于让锁的粒度细一些，更有利于多个线程并发执行的，但偶然间也希望粒度粗点好.
如A给B交接使命，打电话，交接使命1，挂电话。打电话，交接使命2，挂电话。打电话，交接使命3，挂电话。粗化成，打电话，交接使命1，2，3.挂电话。把这三个合并一个粗粒度的锁，粗化进步了效率。
小结：synchronized的优化操作

• 锁升级：偏向锁 -> 轻量级锁 -> 重量级锁
  
• 锁消除：自动干掉不须要的锁
  
• 锁粗化：把多个细粒度的锁合并成一个粗粒度的锁，减少锁竞争。
  

3. CAS（compare and swap）

CAS是一个特殊的cpu的指令，完成的工作就是 比较 和 互换。是单个cpu指令，本身是原子的，同时完成 读取内存，比较是否相称，修改内存。
CAS的伪代码：

比较address内存地址中的值，是否和expected寄存器中的值雷同，假如雷同，就把swap寄存器的值和address内存的值，举行互换，返回true。假如不雷同，直接返回false。

• CAS本身是cpu指令，操作系统对指令举行了封装，jvm又对操作系统提供的api又封装了一层，有的cpu可能会不支持cas，而Java的标准库，对于CAS又举行了进一步的封装，提供了一些工具类，里面最主要的一个工具，原子类。
  
• 之前的线程安全都是靠加锁，加锁-》阻塞-》性能低落。基于CAS指令，不涉及加锁，不会阻塞，合理使用也包管线程安全，即无锁编程。
  

1. public class ThreadDemo34  {
2.     // AtomicInteger: Java标准库中，对cas又进一步的封装，提供了一些工具类，即原子类
3.     // 使用原生的int 会出现线程安全问题 ，不使用加锁，使用AtomicInteger替换int也能保证线程安全
4.     // private static int count = 0;
5.     private static AtomicInteger count = new AtomicInteger(0);
6.     public static void main(String[] args) throws InterruptedException {
7.         Thread t1 = new Thread(() -> {
8.             for (int i = 0; i < 50000; i++) {
9.                 //getAndIncrement 对变量的修改，是一个cas指令，即这个指令天然就是原子的
10.                 //count++;
11.                 count.getAndIncrement();
12.                 // ++count;
13.                 //count.incrementAndGet();
14.                 // count += n;
15.                 //count.getAndAdd(n);
16.             }
17.         });
18.         Thread t2 = new Thread(() -> {
19.             for (int i = 0; i < 50000; i++) {
20.                 //count++;
21.                 count.getAndIncrement();
22.             }
23.         });
25.         t1.start();
26.         t2.start();
28.         t1.join();
29.         t2.join();
31.         System.out.println(count);
32.     }
33. }

复制代码

3.1 CAS 的ABA题目怎么办理

假如去ATM取钱，里面有1000，要取500，取钱的时间ATM卡了，按了一下没反应（t1线程），又按了一下（t2线程），此时此时产生了两个线程，去尝试扣款操作，此处 假如按CAS的方式扣款，这样是没题目的。当又来个t3线程给账户存了500，此时t1线程就不知道当前的1000是始终没变还是变了又变返来了。
办理方案：

• 约定数据变革是单向的（只能增加或者只能减少），不能是双向的（即又增加又能减少）。
  
• 对于本身就必须双向变革的数据，可以给它引入一个版本号，版本号这个数字是只能增加，不能减少。
  

4. Callable接口

• 继续Thread（包含了匿名内部类的方式）
  
• 实现Runnable（包含了匿名内部类的方式）
  
• 基于lambda
  
• 基于Callable
  
• 基于线程池
  

• Runnable关注的是这个过程，不关注执行结果，Runnable提供的是run方法，返回值类型是void
  

1. public class ThreadDemo35 {
2.     private static  int sum = 0;
3.     public static void main(String[] args) throws InterruptedException {
4.         // 创建一个新线程，用新的线程实现从1+到1000
6.         // 不用callable
7.         Thread t = new Thread(new Runnable() {
8.             @Override
9.             public void run() {
10.                 int result = 0;
11.                 for (int i = 0; i <= 1000; i++) {
12.                     result += i;
13.                 }
14.                 sum = result;
15.             }
16.         });
17.         t.start();
18.         t.join();
19.         // 主线程获取到计算结果
20.         // 此处想要获取到结果，就需要弄一个成员变量保持上述结果
21.         System.out.println("sum= " + sum);
22.     }
23. }

复制代码

• Callable要关注执行结果，Callable提供的call方法，返回值就是线程执利用命得到的结果
  
• callable 通常搭配FutureTask来使用，FutureTask用来生存Callable的返回结果，因为callable往往是在另一个线程中执行的，什么时间执行完不确定。
  
• FutureTask类，作为Thread和callable的粘合剂，使用futureTask.get()获取结果，带有阻塞功能，假如线程还没有执行完，get就会阻塞，等待线程执行完。
  当编写多线程代码，希望关注线程中代码的返回值的时间：
  相比于runnable来说，不必要引入额外的成员变量，直接借助这个的返回值即可。
  

1. import java.util.concurrent.*;
3. // Callable 接口
4. public class ThreadDemo36 {
5.     public static void main(String[] args) throws ExecutionException, InterruptedException {
6.         // 期望线程的入口方法里，返回值是啥类型，此处的泛型就是什么类型 这里希望返回值是Integer
7.         Callable<Integer> callable = new Callable<Integer>() {
8.             @Override
9.             public Integer call() throws Exception {
10.                 int result = 0;
11.                 for (int i = 0; i <= 1000; i++) {
12.                     result += i;
13.                 }
14.                 return result;
15.             }
16.         };
17.         //Thread没有提供构造函数传入callable
18.         // 引入一个FutureTask类，作为Thread和callable的粘合剂 未来的任务，相当于一个凭据
19.         FutureTask<Integer> futureTask = new FutureTask<>(callable);
20.                
21.         Thread t = new Thread(futureTask);
22.         t.start();
24.         // 接下来这个代码不需要join，使用futureTask获取到结果
25.         // futureTask.get() 这个操作也具有阻塞功能，如果线程还没有执行完毕，get就会阻塞，等到线程执行完了，
26.             //return的结果就会被get返回回来
27.         System.out.println(futureTask.get());
28.     }
29. }

复制代码

5. JUC（java.util.concurrent）的常见类

5.1 ReentrantLock

用法：

• lock() :加锁,假如获取不到锁就死等
  
• unlock()，解锁
  
• trylock(超出时间)：加锁，假如获取不到锁，等待肯定的时间之后就放弃加锁。
  ReentrantLock,可重入锁，和synchronized一样是可重入锁，有了synchronized为什么还必要ReentrantLock：
  

• ReentrantLock提供了tryLock操作，lock直接举行加锁，假如加锁不成，就要阻塞；tryLock，尝试举行加锁，假如加锁不乐成，不阻塞，直接返回false，即tryLock提供了更多的可操作空间。
  
• Reentrant Lock提供了公平锁的实现（通过队列记载加锁线程的先后顺序），ReentrantLock构造方法中填写参数，就可以设置公平锁，而synchronized黑白公平锁。
  
• 搭配的等待通知机制差别的，synchronized，搭配wait / notify，对于Reentrant Lock，搭配Condition类，功能比wait / notify 略强一点。
  

6. 信号量Semaphore

信号量，用来体现 可用资源的个数，本质上就是一个计数器。

1. import java.util.concurrent.Semaphore;
3. // 信号量 Semaphore
4. public class ThreadDemo37 {
5.     public static void main(String[] args) throws InterruptedException {
6.         Semaphore semaphore = new Semaphore(1);
7.         // 申请1个资源
8.         semaphore.acquire();
9.         System.out.println("P 操作");
10.         semaphore.acquire();
11.         System.out.println("P 操作");
12.         // 释放一个资源
13.         semaphore.release();
14.         System.out.println("V 操作");
15.     }
16. }

复制代码

• new一个semaphore对象，有1个可用资源
  
• semaphore.acquire ：申请一个资源，资源个数 -1（P操作）
  
• semaphore.release ：开释一个资源，资源个数 +1 （V操作）
  
• 假如计数器为0，即没有可用资源了，还申请资源，就会阻塞等待，直到有其他线程开释资源。
  
• Semaphore的PV操作的加减操作都是原子的，可以在多线程下直接使用。
  

所谓的锁，本质上也是一种特殊的信号量，锁，可以认为计数值为1的信号量，开释状态，就是1，加锁状态，就是0，对于非0即1的信号量，称为二元信号量，信号量是更广义的锁。
6.1 使用Semaphore可以包管线程安全，就相当于synchronized加锁

使用Semaphore，先申请一个资源然后举行下述count++操作，再举行开释操作，这样也可以确保线程安全。

1. import java.util.concurrent.Semaphore;
3. // 信号量 Semaphore
4. // 在操作前先申请一个可用资源 使数字-1 semaphore.acquire();  后semaphore.release(); 数字+1 释放一个可用资源
5. // 加锁状态， 就是 0 ，释放状态，就是1 对于非0即1的信号量就称为 二元信号量
6. public class ThreadDemo38 {
7.     private static int count = 0;
8.     public static void main(String[] args) throws InterruptedException {
9.         Semaphore semaphore = new Semaphore(1);
10.         Thread t1 = new Thread(() -> {
11.             for (int i = 0; i < 50000; i++) {
12.                 try {
13.                     semaphore.acquire();
14.                 } catch (InterruptedException e) {
15.                     e.printStackTrace();
16.                 }
17.                 count++;
18.                 semaphore.release();
19.             }
20.         });
21.         Thread t2 = new Thread(() -> {
22.             for (int i = 0; i < 50000; i++) {
23.                 try {
24.                     semaphore.acquire();
25.                 } catch (InterruptedException e) {
26.                     e.printStackTrace();
27.                 }
28.                 count++;
29.                 semaphore.release();
30.             }
31.         });
32.         t1.start();
33.         t2.start();
34.         t1.join();
35.         t2.join();
36.         System.out.println(count);
37.     }
38. }

复制代码

小结
确保线程安全的操作：

• synchronized
  
• ReentrantLock
  
• CAS（原子类）
  
• Semaphore
  

7. CountDownLatch

CountDownLatch，同时等待N个使命执行竣事，比如，多线程执行一个使命，把大的使命拆成几个部门，由每个线程分别执行。

• 构造CountDownLatch实例，初始化10体现10个使命线程必要完成
  
• 每个使命执行完毕，都调用latch.countDown()，在CountDownLatch 内部的计数器同时自减
  
• 主线程中使用latch.await()，阻塞等待所有使命竣事，相当于计数器为0
  

** join() ,就只能每个线程执行一个使命，而使用CountDownLatch就可以一个线程执行多个使命**。

1. public class ThreadDemo39 {
2.     public static void main(String[] args) throws InterruptedException {
3.         // 1.此处构造方法中写10，意思是有10个线程任务
4.         CountDownLatch latch = new CountDownLatch(10);
5.         // 创建出 10个线程负责下载
6.         for (int i = 0; i < 10; i++) {
7.             int id = i;
8.             Thread t = new Thread(() -> {
9.                 Random random = new Random();
10.                 int time = (random.nextInt(5) + 1) * 1000;
11.                 System.out.println("线程 "+id+"开始下载");
12.                 try {
13.                     Thread.sleep(time);
14.                 } catch (InterruptedException e) {
15.                     e.printStackTrace();
16.                 }
17.                 System.out.println("线程结束 " + id + "结束下载");
18.                 // 2.告知 CountDownLacth 执行结束了
19.                 latch.countDown();
20.             });
21.             t.start();
22.         }
24.         // 3. 通过await操作等待所有任务结束，也就是 countDown被调用10次
25.         latch.await();
26.         System.out.println("所有任务都已经完成了");
27.     }
28. }

复制代码

8. ConcurrentHashMap

多线程环境下HashMap线程不安全，使用哈希表（Hashtable）就在关键方法上添加synchronized。

• ConcurrentHashMap的读是否要加锁？
  读操作没有加锁，目的是为了进一步低落锁冲突的概率，为了包管读到刚修改的数据，搭配了volatile关键字。
  
• 先容ConcurrentHashMap的锁分段技能？
  把若干个哈希桶分成一个段，针对每个段分别加锁，这个是Java1.7中接纳的技能，Java1.8不再使用，
  

8.1 ConcurrentHashMap（Java1.8）的改进

• 缩小了锁的粒度
  在Hashtable，直接在方法上使用synchronized，就相当于是对this加锁，此时尝试修改两个差别链表上的元素，都会触发锁冲突。假如修改两个差别链表上的元素，就不涉及到线程安全，修改差别变量。假如修改是同一个链表上的元素，就可能出现线程安全题目。
  ConcurrentHashMap 就是把锁变小了，给每个链表都发了一把锁，此时，不是操作同一个链表的锁，就不会产生锁冲突。 不会产生更多的空间代价，因为Java中任何一个对象都可以直接作为锁对象，本身哈希表中，就得有数组，数组的元素都是已经存在的（每个链表的头节点作为加锁对象即可）。
  锁桶（hash表也称为hash桶），构成了一个雷同于桶，每个链表就是构成桶的一个木板，所谓锁桶就是针对每个木板（每个链表）举行分别加锁的。
  
• 充分的使用了CAS原子操作，减少一些加锁
  
• 针对扩容操作的优化：扩容是一个重量操作。负载因子，描述了每个桶上均匀有多少个元素，0.75是负载因子默认的扩容阈值，不是负载因子本体。负载因子是计算出来的：拿着实际的元素个数 / 数组的长度（桶的个数），这个值和扩容阈值举行比较，看是否必要扩容。
  

• 假如太长，1.酿成树（长度不均匀的情况），2.扩容。
  
• 创建一个更大的数组，把旧的hash表的元素都给搬运到（删除/插入）新的数组上，假如hash表本身元素非常多，这里扩容操作就会消耗很长的时间。
  
• ** HashMap的扩容操作是梭哈，在某次插入元素的操作中，整体就举行了扩容。而ConcurrentHashMap，每次操作都只搬运一部门元素。**
  
• 即在扩容的过程中，同时存在两份哈希表，一份新的一份旧的：插入操作：直接往新的上插入；删除操作：新的旧的都是直接删除；查找操作：新的和旧的都得查询一下。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 qidao123.com技术社区-IT企服评测·应用市场 (https://dis.qidao123.com/)

Powered by Discuz! X3.4