面试知识点准备与总结——（并发篇）

「爱情、让人受尽委屈。」 2023-09-29 19:34 5阅读 0赞

#### 目录 ####

*  前言
 *   *  1. 线程有哪些状态
     *  2. 线程池的核心参数
     *  3. sleep和wait的区别
     *  4. lock 与 synchronized 的异同
     *  5. volatile能否保证线程安全
     *  6. 悲观锁和乐观锁的区别
     *  7. Hashtable 与 ConcurrentHashMap 的区别
     *  8. ConcurrentHashMap1.7和1.8的区别
     *  9. ThreadLocal的理解
     *  10. ThreadLocalMap中的key为何要设置为弱引用

## 前言 ##

***本篇主要记录了Java并发相关的面试问题涉及到的知识点透析，如线程状态，线程池，volatile介绍，乐观锁悲观锁，Hashtable，ConcurrentHashMap，ThreadLocal的理解等等，后续遇到新的面试题会继续完善并补充详细，最后感谢您的阅览，愿您终有所获***

> *基础篇地址*：[Java面试准备之基础篇][Java]

> *虚拟机篇地址*：[Java面试准备之虚拟机篇][Java 1]

--------------------

### 1. 线程有哪些状态 ###

Java线程分为六种状态，分别是新建，可运行，终结，阻塞，等待，有时限等待

前面三个新建，运行，终结都是单向不可逆的，而后面的阻塞，等待，有时限等待是可以与运行状态来回变换的

![在这里插入图片描述][2f44fa1776b0497fb9fdb0362ccd26ce.png]

--------------------

### 2. 线程池的核心参数 ###

线程池的核心参数一共有7个

*  `核心线程数`，是指一直保留在线程池里的线程数目
 *  `最大线程数`，是指核心线程数和救急线程数的总和
 *  `生存时间`，是指救急线程的存活时间，当救急线程空闲时间达到这个生存时间后，就会终结
 *  `时间单位`，是指存活时间的单位，是秒还是分钟或者小时
 *  `阻塞队列`，当核心线程用完后，剩下任务就在阻塞队列中排队，这里是指阻塞队列的长度
 *  `线程工厂`，给线程池创建新线程  
    ![在这里插入图片描述][7f7d5782e7b24543b29ae0b04aed7ae4.png]

最后一个是**拒绝策略**，拒绝策略有四种，如下

![在这里插入图片描述][70b4b49258ca40a8b8fb29d8425afb4b.png]

当任务数量超过核心线程数量，最大排队数量以及临时线程数量的总和，全负载时，多余任务会根据线程池的拒绝策略来丢弃或处理

--------------------

### 3. sleep和wait的区别 ###

**一个共同点，三个不同点**

共同点

> wait() ，wait(long) 和 sleep(long) 的效果都是让当前线程暂时放弃 CPU 的使用权，进入阻塞状态

不同点

*  方法归属不同
    
     *  sleep(long) 是 Thread 的静态方法
     *  而 wait()，wait(long) 都是 Object 的成员方法，每个对象都有
 *  醒来时机不同
    
     *  执行 sleep(long) 和 wait(long) 的线程都会在等待相应毫秒后醒来
     *  wait(long) 和 wait() 还可以被 notify 唤醒，wait() 如果不唤醒就一直等下去
     *  它们都可以被打断唤醒
 *  锁特性不同（重点）
    
     *  wait 方法的调用**必须先获取 wait 对象的锁**，而 sleep 则无此限制
     *  wait 方法执行后会释放对象锁，允许其它线程获得该对象锁（我放弃 cpu，但你们还可以用）
     *  而 sleep 如果在 synchronized 代码块中执行，并不会释放对象锁（我放弃 cpu，你们也用不了）  
        （这里简单可以理解，wait释放锁睡觉，sleep抱着锁睡觉）

![在这里插入图片描述][deb58b38299e48618143044c9b11b3ad.png]

--------------------

### 4. lock 与 synchronized 的异同 ###

**可以从三个层面分解**

***不同点***

①语法层面

*  synchronized 是关键字，源码在 jvm 中，用 c++ 语言实现
 *  Lock 是接口，源码由 jdk 提供，用 java 语言实现
 *  使用 synchronized 时，退出同步代码块锁会自动释放，而使用 Lock 时，需要手动调用 unlock 方法释放锁

②功能层面

*  二者均属于悲观锁、都具备基本的互斥、同步、锁重入（可以加多道锁）功能
 *  Lock 提供了许多 synchronized 不具备的功能，例如获取等待状态（哪些线程被阻塞了）、公平锁、可打断、可超时（可设置最大超时时间，超过指定时间放弃获取锁）、多条件变量
 *  Lock **有适合不同场景的实现**，如 ReentrantLock（可重入锁）， ReentrantReadWriteLock（读多写少场景）

③性能层面

*  在没有竞争时（或竞争很少时），synchronized 做了很多优化，如偏向锁、轻量级锁，性能不赖
 *  在竞争激烈时，Lock 的实现通常会提供更好的性能

--------------------

> **Lock锁，是用创建的锁对象调用lock()，unlock()方法，上锁和释放锁  
> synchronized ，是同步代码块或同步方方法的方式**

--------------------

**公平锁**

*  公平锁的公平体现
    
     *  **已经处在阻塞队列**中的线程（不考虑超时）始终都是公平的，先进先出
     *  公平锁是指**未处于阻塞队列**中的线程来争抢锁，如果队列不为空，则老实到队尾等待
     *  非公平锁是指**未处于阻塞队列**中的线程来争抢锁，与队列头唤醒的线程去竞争，谁抢到算谁的
 *  公平锁会降低吞吐量，一般不用

**条件变量**

*  ReentrantLock 中的条件变量功能类似于普通 synchronized 的 wait，notify，用在当线程获得锁后，发现条件不满足时，临时等待的链表结构
 *  与 synchronized 的等待集合不同之处在于，ReentrantLock 中的条件变量可以有多个，可以实现更精细的等待、唤醒控制

--------------------

### 5. volatile能否保证线程安全 ###

线程安全要考虑三个方面:可见性、有序性、原子性

①可见性指，一个线程对共享变量修改，另一个线程能看到最新的结果

②有序性指，一个线程内代码按编写顺序执行

③原子性指，一个线程内多行代码以一个整体运行，期间不能有其它线程的代码插队

--------------------

**原子性**

*  起因：多线程下，不同线程的**指令发生了交错**导致的共享变量的读写混乱
 *  解决：用悲观锁或乐观锁解决，volatile 并不能解决原子性

**可见性**

*  起因：由于**编译器优化、或缓存优化、或 CPU 指令重排序优化**导致的对共享变量所做的修改另外的线程看不到
 *  解决：用 volatile 修饰共享变量，能够防止编译器等优化发生，让一个线程对共享变量的修改对另一个线程可见

--------------------

*下面就是一个典型的永远循环-可见性案例*

![在这里插入图片描述][9d4aa7047b80432cbd1d40e739472bd7.png]  
**那到底是什么原因导致了线程0修改stop值后，主线程仍然继续循环，而线程1获取的stop又显示为true呢？**

其中就是JIT的起的作用，JIT是优化器，对热点的字节码文件进行优化，例如频繁调用的方法，反复执行的循环；

在线程0还没有改变stop的值时，主线程在线程0睡眠的100毫秒内，已经执行了几百万次了，这时优化器JIT坐不住了，就对这个反复读取的stop且每次读取值都相同的字节码做优化，避免它频繁从内存中读取，把stop认为是false，把它的字节码编译成机器码缓存起来，再次循环时，就直接拿这个机器码，节省中间解释过程。如下图

![在这里插入图片描述][505f90c678e94d71b9a989c2d15b6867.png]

--------------------

若上面那个stop变量用了volatile修饰，JIT就不会对其优化，放过它  
**有序性**

*  起因：由于**编译器优化、或缓存优化、或 CPU 指令重排序优化**导致指令的实际执行顺序与编写顺序不一致
 *  解决：用 volatile 修饰共享变量会在读、写共享变量时加入不同的屏障，阻止其他读写操作越过屏障，从而达到阻止重排序的效果
 *  注意：
    
     *  **volatile 变量写**加的屏障是阻止上方其它写操作越过屏障排到 **volatile 变量写**之下
     *  **volatile 变量读**加的屏障是阻止下方其它读操作越过屏障排到 **volatile 变量读**之上
     *  volatile 读写加入的屏障只能防止同一线程内的指令重排

> 写是上面操作不能越过下面（避免被程序之前的数据覆盖），读是下面操作不能越过上面（避免读取的是程序后面的数据）

***是不能逆着箭头排的***  
![在这里插入图片描述][94beaec12d8049a3bb99c9b705251471.png]

--------------------

### 6. 悲观锁和乐观锁的区别 ###

**对比悲观锁与乐观锁**

*  悲观锁的代表是 synchronized 和 Lock 锁
    
     *  其核心思想是【线程只有占有了锁，才能去操作共享变量，每次只有一个线程占锁成功，获取锁失败的线程，都得停下来等待】
     *  线程从运行到阻塞、再从阻塞到唤醒，涉及线程上下文切换，如果频繁发生，影响性能
     *  实际上，线程在获取 synchronized 和 Lock 锁时，如果锁已被占用，都会做几次重试操作，减少阻塞的机会
 *  乐观锁的代表是 AtomicInteger，使用 cas （*compareAndSetInt*方法，比较并交换的缩写）来保证原子性
    
     *  其核心思想是【无需加锁，每次只有一个线程能成功修改共享变量，其它失败的线程不需要停止，**不断重试直至成功**】
     *  由于线程一直运行，不需要阻塞，因此不涉及线程上下文切换
     *  它需要多核 cpu 支持，且线程数不应超过 cpu 核数

--------------------

cas方法是从乐观的角度出发，假设每次获取数据别人都不会修改，所以不会上锁。只不过在修改共享数据的时候，会检查一下，把传入的旧值和当前共享变量的最新值作比较，来判断别人有没有修改过这个数据。

如果别人修改过，那么我再次获取现在最新的值。

如果别人没有修改过，那么我现在直接修改共享数据的值.(乐观锁）

CAS是要和volatile一起使用，这样才能保证每次看到的共享变量是最新值

--------------------

synchronized 加锁是使用的互斥方式，将多行代码作为一个整体执行，保证并发下的原子性

而CAS没有互斥，是并发执行，只是在修改操作时，用比较并交换的原则，来判断传入的旧值和当前获取的最新值是否一致（看看你要更新的值有没有被人修改过），一致才修改成功，不一致则修改失败，修改失败也无所谓，因为乐观锁是不断重试直至成功，在while（true）循环中，再拿到新值，在最新值得基础上做更新操作

***下面是代码演示***

> synchronized 悲观锁

![在这里插入图片描述][404e9eb687764a9798d7ddb3771aca59.png]

--------------------

> CAS 乐观锁

![在这里插入图片描述][b68cfcb7586240df895f5878c117b311.png]

--------------------

### 7. Hashtable 与 ConcurrentHashMap 的区别 ###

**Hashtable 对比 ConcurrentHashMap**

*  Hashtable 与 ConcurrentHashMap 都是线程安全的 Map 集合
 *  Hashtable 并发度低，整个 Hashtable 对应一把锁，同一时刻，只能有一个线程操作它
 *  ConcurrentHashMap 并发度高，整个 ConcurrentHashMap 对应多把锁，只要线程访问的是不同锁，那么不会冲突

（Hashtable的底层实现是数组+链表结构实现的；hashtable的容量是质数，有较好的分布性，不需要进行二次哈希）

--------------------

### 8. ConcurrentHashMap1.7和1.8的区别 ###

**ConcurrentHashMap 1.7**

*  数据结构：`Segment(大数组) + HashEntry(小数组) + 链表`，每个 Segment 对应一把锁，如果多个线程访问不同的 Segment，则不会冲突
 *  并发度：Segment 数组大小即并发度，决定了同一时刻最多能有多少个线程并发访问。Segment 数组不能扩容，意味着并发度在 ConcurrentHashMap 创建时就固定了
 *  索引计算
    
     *  假设大数组长度是  2 m 2^m 2m，key 在大数组内的索引是 key 的二次 hash 值的高 m 位（例如：capacity为32，32是2的5次方，取二次hash值高5位，就是前5位，转十进制就得到存储位置索引值）
     *  假设小数组长度是  2 n 2^n 2n，key 在小数组内的索引是 key 的二次 hash 值的低 n 位
 *  扩容：每个小数组的扩容相对独立，**小数组在超过扩容因子时会触发扩容**，每次扩容翻倍；由于ConcurrentHashMap1.7是加锁了的，即使链表使用头插法，也不会像HashMap1.7那样导致死链
 *  Segment\[0\] 原型：首次创建其它小数组时，会以此原型为依据，数组长度，扩容因子都会以原型为准，下图作为演示  
    ![在这里插入图片描述][dddece7fcae14740805d551a6019b8cb.png]  
    新的小数组会根据当前segment\[0\]做为原型来创建
 *  小数组容量最小是2；小数组容量 = 大数组容量 / 可并发数

--------------------

下面来个图，有图有真相  
并发度决定蓝色数组的大小，容量决定小数组entry的大小  
![在这里插入图片描述][c5d381af5cac4f92849edff0d33086b4.png]

--------------------

**ConcurrentHashMap 1.8**

*  数据结构：`Node 数组 + 链表或红黑树`，数组的每个头节点作为锁，如果多个线程访问的头节点不同，则不会冲突。首次生成头节点时如果发生竞争，利用 cas 而非 syncronized，进一步提升性能  
    ![在这里插入图片描述][ba840b623834463383c74b369b2c78dc.png]
 *  并发度：**Node 数组有多大，并发度就有多大**，与 1.7 不同，Node 数组可以扩容
 *  扩容条件：Node 数组满 3/4 时就会扩容，1.7是超出才扩容
 *  扩容单位：以链表为单位从后向前迁移链表，迁移完成的将旧数组头节点替换为 ForwardingNode
 *  扩容时并发 get
    
     *  根据是否为 ForwardingNode 来决定是在新数组查找还是在旧数组查找，不会阻塞  
        ![在这里插入图片描述][f94931c1b88d457b89e07efe72e13a7e.png]
     *  如果链表长度超过 1，则需要对节点进行复制（创建新节点），怕的是节点迁移后 next 指针改变
     *  如果链表最后几个元素扩容后索引不变，则节点无需复制  
        ![在这里插入图片描述][19c69b7b7fa74541bea1c30f50bfeb4a.png]
 *  扩容时并发 put
    
     *  如果 put 的线程与扩容线程操作的链表是同一个，put 线程会阻塞
     *  如果 put 的线程操作的链表还未迁移完成，即头节点不是 ForwardingNode，则可以并发执行
     *  如果 put 的线程操作的链表已经迁移完成，即头结点是 ForwardingNode，则可以协助扩容
 *  capacity 代表预估的元素个数，capacity / factory 来计算出初始数组大小，需要贴近  2 n 2^n 2n

> 例如，要放16个元素（capacity为16），但是数组满扩容因子就会扩容，如果数组长度为16是不够的，所以数组容量 = capacity / factory；简单说就是capacity是数组容量的3/4.

*  loadFactor **只在计算初始数组大小时被使用**，之后扩容固定为 3/4
 *  超过树化阈值时的扩容问题，如果容量已经是 64，直接树化，否则在原来容量基础上做 3 轮扩容

> ***区别***

`①从底层结构上`  
1.7ConcurrentHashMap 底层数据结构是**Segment(大数组) + HashEntry(小数组) + 链表**  
而1.8 ConcurrentHashMap 底层数据结构是 **数组 + 链表或红黑树**，而且链表添加元素上不同于1.7的头插法，而是尾插法

`②从初始化的时机上`  
**与 1.7 相比是懒惰初始化**，1.7是饿汉式初始化，初始化以后，数组及数组零号元素已经创建出来了，1.8是在第一次put元素时，才会创建底层数组结构，是懒汉式初始化

`③从扩容时机上`  
1.7是容量**超出**扩容因子才扩容  
而1.8是数组**满** 3/4（或扩容因子\*数组容量) 时就会扩容

--------------------

### 9. ThreadLocal的理解 ###

*  ThreadLocal 可以实现【资源对象】的线程隔离，让每个线程各用各的【资源对象】，避免争用引发的线程安全问题
 *  ThreadLocal 同时实现了线程间的线程隔离和线程内（只要是同一个线程，可以在多个方法中获取同一变量的）资源共享

--------------------

**原理**

每个线程内有一个 ThreadLocalMap 类型的集合，用来存储资源对象

*  调用 set 方法，就是以 ThreadLocal 自己作为 key，资源对象作为 value，放入当前线程的 ThreadLocalMap 集合中
 *  调用 get 方法，就是以 ThreadLocal 自己作为 key，到当前线程中查找关联的资源值
 *  调用 remove 方法，就是以 ThreadLocal 自己作为 key，移除当前线程关联的资源值

线程间的资源是隔离的，key（ThreadLocal)可以相同，但关联的资源池可能不同

![在这里插入图片描述][32d782eeeab24a97bd1e68005b27f405.png]

**ThreadLocalMap**  
key 的 hash 值统一分配；初始容量为16；元素个数满2/3（扩容因子），数组扩容原来两倍，索引值相同时，不再使用链表那种拉链法，而是使用开放寻址法（从这索引开始，找下一个空闲位置作为索引位置）。

--------------------

### 10. ThreadLocalMap中的key为何要设置为弱引用 ###

**弱引用 key**

ThreadLocalMap 中的 key 被设计为弱引用，原因如下

*  Thread 可能需要长时间运行（如线程池中的线程），如果 key 不再使用，需要在内存不足（GC）时释放其占用的内存

--------------------

**内存释放时机**

①被动 GC 释放 key

*  仅是让 key 的内存释放，关联 value 的内存并不会释放

--------------------

② 懒惰被动释放 value

*  get key 时，发现是 null key，则释放其 value 内存；（当ThreadLocalMap根据key去get值时，发现key不存在，会放入一个为null的key；这是和其他map的不同之处）
 *  set key 时，会使用启发式扫描，清除临近的 null key 的 value 内存，启发次数与元素个数，是否发现 null key 有关

--------------------

③主动 remove 释放 key，value

*  会同时释放 key，value 的内存，也会清除临近的 null key 的 value 内存
 *  推荐使用它，**因为一般使用 ThreadLocal 时都把它作为静态变量**（即强引用），因此无法被动依靠 GC 回收  
    ![在这里插入图片描述][83b75d72dced4aa2b1b981a31c722591.png]  
    所以①和②两种方法都不可用，最好还是主动回收掉

[Java]: http://t.csdn.cn/ytNb7
[Java 1]: http://t.csdn.cn/mWJbT
[2f44fa1776b0497fb9fdb0362ccd26ce.png]: https://img-blog.csdnimg.cn/2f44fa1776b0497fb9fdb0362ccd26ce.png
[7f7d5782e7b24543b29ae0b04aed7ae4.png]: https://img-blog.csdnimg.cn/7f7d5782e7b24543b29ae0b04aed7ae4.png
[70b4b49258ca40a8b8fb29d8425afb4b.png]: https://img-blog.csdnimg.cn/70b4b49258ca40a8b8fb29d8425afb4b.png
[deb58b38299e48618143044c9b11b3ad.png]: https://img-blog.csdnimg.cn/deb58b38299e48618143044c9b11b3ad.png
[9d4aa7047b80432cbd1d40e739472bd7.png]: https://img-blog.csdnimg.cn/9d4aa7047b80432cbd1d40e739472bd7.png
[505f90c678e94d71b9a989c2d15b6867.png]: https://img-blog.csdnimg.cn/505f90c678e94d71b9a989c2d15b6867.png
[94beaec12d8049a3bb99c9b705251471.png]: https://img-blog.csdnimg.cn/94beaec12d8049a3bb99c9b705251471.png
[404e9eb687764a9798d7ddb3771aca59.png]: https://img-blog.csdnimg.cn/404e9eb687764a9798d7ddb3771aca59.png
[b68cfcb7586240df895f5878c117b311.png]: https://img-blog.csdnimg.cn/b68cfcb7586240df895f5878c117b311.png
[dddece7fcae14740805d551a6019b8cb.png]: https://img-blog.csdnimg.cn/dddece7fcae14740805d551a6019b8cb.png
[c5d381af5cac4f92849edff0d33086b4.png]: https://img-blog.csdnimg.cn/c5d381af5cac4f92849edff0d33086b4.png
[ba840b623834463383c74b369b2c78dc.png]: https://img-blog.csdnimg.cn/ba840b623834463383c74b369b2c78dc.png
[f94931c1b88d457b89e07efe72e13a7e.png]: https://img-blog.csdnimg.cn/f94931c1b88d457b89e07efe72e13a7e.png
[19c69b7b7fa74541bea1c30f50bfeb4a.png]: https://img-blog.csdnimg.cn/19c69b7b7fa74541bea1c30f50bfeb4a.png
[32d782eeeab24a97bd1e68005b27f405.png]: https://img-blog.csdnimg.cn/32d782eeeab24a97bd1e68005b27f405.png
[83b75d72dced4aa2b1b981a31c722591.png]: https://img-blog.csdnimg.cn/83b75d72dced4aa2b1b981a31c722591.png