周阳大厂面试第二季(并发编程)
大厂面试题之JUC多线程及高并发
1. 谈谈你对volatile的理解
1.1 volatile是Java虚拟机提供的轻量级的同步机制
- 保证可见性
- 禁止指令排序
- 不保证原子性
1.2 JMM(Java 内存模型) 你谈谈
基本概念
- JMM 本身是一种抽象的概念并不是真实存在,它描述的是一组规定或则规范,通过这组规范定义了程序中的访问方式。
- JMM 同步规定
- 线程解锁前,必须把共享变量的值刷新回主内存
- 线程加锁前,必须读取主内存的最新值到自己的工作内存
- 加锁解锁是同一把锁
- 由于 JVM 运行程序的实体是线程,而每个线程创建时 JVM 都会为其创建一个工作内存,工作内存是每个线程的私有数据区域,而 Java 内存模型中规定所有变量的储存在主内存,主内存是共享内存区域,所有的线程都可以访问,但线程对变量的操作(读取赋值等)必须都工作内存进行看。
- 首先要将变量从主内存拷贝的自己的工作内存空间,然后对变量进行操作,操作完成后再将变量写回主内存,不能直接操作主内存中的变量,工作内存中存储着主内存中的变量副本拷贝,前面说过,工作内存是每个线程的私有数据区域,因此不同的线程间无法访问对方的工作内存,线程间的通信(传值)必须通过主内存来完成。
- 内存模型图

三大特性
- 可见性
1 | /** |
输出结果:
1 | thread1 come in |
当我们加上volatile关键字后,volatile int num = 0;输出结果为:
1 | thread1 come in |
如果不加 volatile 关键字,则主线程会进入死循环,加 volatile 则主线程能够退出,说明加了 volatile 关键字变量,当有一个线程修改了值,会马上被另一个线程感知到,当前值作废,从新从主内存中获取值。对其他线程可见,这就叫可见性。
- 原子性
原子性:不可分割、完整性,即某个线程正在做某个具体业务时,中间不可以被加塞或者被分割,需要整体完整,要么同时成功,要么同时失败
验证示例(变量添加volatile关键字,方法不添加synchronized):
1 | import java.util.concurrent.TimeUnit; |
执行三次结果为:
1 | //1. |
- 有序性
计算机在执行程序时,为了提高性能,编译器个处理器常常会对指令做重排,一般分为以下 3 种

编译器优化的重排
指令并行的重排
内存系统的重排
单线程环境里面确保程序最终执行的结果和代码执行的结果一致
处理器在进行重排序时必须考虑指令之间的数据依赖性
多线程环境中线程交替执行,由于编译器优化重排的存在,两个线程中使用的变量能否保证用的变量能否一致性是无法确定的,结果无法预测
代码如下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18public class ReSortSeqDemo {
int a = 0;
boolean flag = false;
public void method01() {
a = 1; // flag = true;
// ----线程切换----
flag = true; // a = 1;
}
public void method02() {
if (flag) {
a = a + 3;
System.out.println("a = " + a);
}
}
}如果两个线程同时执行,method01 和 method02 如果线程 1 执行 method01 重排序了,然后切换的线程 2 执行 method02 就会出现不一样的结果。
禁止指令重排小总结(了解)
volatile实现禁止指令重排,从而避免了多线程环境下程序出现乱序执行的现象
内存屏障(Memory Barrier)又称内存栅栏,是一个CPU指令,他的作用有两个:
- 保证特定操作的执行顺序
- 保证某些变量的内存可见性(利用该特性实现volatile的内存可见性)
由于编译器和处理器都能执行指令重排优化。如果在之零件插入一i奥Memory Barrier则会告诉编译器和CPU,不管什么指令都不能和这条Memory Barrier指令重排顺序,也就是说==通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化==。内存屏障另外一个作用是强制刷出各种CPU的缓存数据,因此任何CPU上的线程都能读取到这些数据的最新版本。
下面是保守策略下,volatile写插入内存屏障后生成的指令序列示意图:

下面是在保守策略下,volatile读插入内存屏障后生成的指令序列示意图:

线程安全性保证
- 工作内存与主内存同步延迟现象导致可见性问题
- 可以使用 synchronzied 或 volatile 关键字解决,它们可以使用一个线程修改后的变量立即对其他线程可见
- 对于指令重排导致可见性问题和有序性问题
- 可以利用 volatile 关键字解决,因为 volatile 的另一个作用就是禁止指令重排序优化
1.3 你在哪些地方用到过volatile?
单例模式DCL代码
1 | public class Singleton02 { |
如果没有加 volatile 就不一定是线程安全的,原因是指令重排序的存在,加入 volatile 可以禁止指令重排。
原因是在于某一个线程执行到第一次检测,读取到的 instance 不为 null 时,instance 的引用对象可能还没有完成初始化。
instance = new Singleton()可以分为以下三步完成1
2
3memory = allocate(); // 1.分配对象空间
instance(memory); // 2.初始化对象
instance = memory; // 3.设置instance指向刚分配的内存地址,此时instance != null步骤 2 和步骤 3 不存在依赖关系,而且无论重排前还是重排后程序的执行结果在单线程中并没有改变,因此这种优化是允许的。
发生重排
1
2
3memory = allocate(); // 1.分配对象空间
instance = memory; // 3.设置instance指向刚分配的内存地址,此时instance != null,但对象还没有初始化完成
instance(memory); // 2.初始化对象所以不加 volatile 返回的实例不为空,但可能是未初始化的实例
2. CAS你知道吗
2.1 compareAndSet—-比较并交换
- 例子:
1 | package com.jian8.juc.cas; |
- 输出结果为:
1 | true current data is 2019 |
2.2 CAS底层原理?如果知道,谈谈你对UnSafe的理解
atomicInteger.getAndIncrement();
1 | atomicInteger.getAndIncrement()方法的源代码: |
UnSafe
1 | public class AtomicInteger extends Number implements java.io.Serializable { |
- Unsafe 是 CAS 的核心类,由于 Java 方法无法直接访问底层系统,而需要通过本地(native)方法来访问, Unsafe 类相当一个后门,基于该类可以直接操作特定内存的数据。Unsafe 类存在于 sun.misc 包中,其内部方法操作可以像 C 指针一样直接操作内存,因为 Java 中 CAS 操作执行依赖于 Unsafe 类。
- 变量 vauleOffset,表示该变量值在内存中的偏移量,因为 Unsafe 就是根据内存偏移量来获取数据的。
- 变量 value 用 volatile 修饰,保证了多线程之间的内存可见性。

CAS是什么
CAS的全称为Compare-And-Swap ,它是一条CPU并发原语.
它的功能是判断内存某个位置的值是否为预期值,如果是则更新为新的值,这个过程是原子的.
CAS并发原语提现在Java语言中就是sun.miscUnSaffe类中的各个方法.调用UnSafe类中的CAS方法,JVM会帮我实现CAS汇编指令.这是一种完全依赖于硬件 功能,通过它实现了原子操作,再次强调,由于CAS是一种系统原语,原语属于操作系统用于范畴,是由若干条指令组成,用于完成某个功能的一个过程,并且原语的执行必须是连续的,在执行过程中不允许中断,也即是说CAS是一条原子指令,不会造成所谓的数据不一致的问题.



- 分析一下 unSafe.getAndIncrement这个方法
1 | var1 AtomicInteger对象本身. |

假设线程A和线程B两个线程同时执行getAndAddInt操作(分别在不同的CPU上):
1.AtomicInteger里面的value原始值为3,即主内存中AtomicInteger的value为3,根据JMM模型,线程A和线程B各自持有一份值为3的value的副本分别到各自的工作内存.
2.线程A通过getIntVolatile(var1,var2) 拿到value值3,这是线程A被挂起.
3.线程B也通过getIntVolatile(var1,var2) 拿到value值3,此时刚好线程B没有被挂起并执行compareAndSwapInt方法比较内存中的值也是3 成功修改内存的值为4 线程B打完收工 一切OK.
4.这是线程A恢复,执行compareAndSwapInt方法比较,发现自己手里的数值和内存中的数字4不一致,说明该值已经被其他线程抢先一步修改了,那A线程修改失败,只能重新来一遍了.
5.线程A重新获取value值,因为变量value是volatile修饰,所以其他线程对他的修改,线程A总是能够看到,线程A继续执行compareAndSwapInt方法进行比较替换,直到成功.
- 底层汇编

- 简单版小总结
CAS (CompareAndSwap)
比较当前工作内存中的值和主内存中的值,如果相同则执行规定操作,否则继续比较直到主内存和工作内存中的值一致为止.
CAS应用
CAS有3个操作数,内存值V,旧的预期值A,要修改的更新值B。
当且仅当预期值A和内存值V相同时,将内存值V修改为B,否则什么都不做。
2.3 CAS缺点
循环时间长开销很大

只能保证一个共享变量的原子性
- 对于多个共享变量操作时,循环 CAS 就无法保证操作的原子性。
引出来ABA问题???
3. 原子类AtomicInteger的ABA问题谈谈?原子更新引用知道吗
3.1 ABA问题的产生
CAS算法实现一个重要前提需要去除内存中某个时刻的数据并在当下时刻比较并替换,那么在这个时间差类会导致数据的变化。
比如线程1从内存位置V取出A,线程2同时也从内存取出A,并且线程2进行一些操作将值改为B,然后线程2又将V位置数据改成A,这时候线程1进行CAS操作发现内存中的值依然时A,然后线程1操作成功。
尽管线程1的CAS操作成功,但是不代表这个过程没有问题
3.2 原子引用 –AtomicReferenceDemo
示例代码:
1 | package juc.cas; |
输出结果
1 | true User(userName=李四, age=23) |
ABA 问题是怎么产生的
1 | /** |
当有一个值从 A 改为 B 又改为 A,这就是 ABA 问题。
3.3 时间戳原子引用
新增机制,修改版本号
1 | import java.util.concurrent.TimeUnit; |
输出结果:
1 | =====以下时ABA问题的产生===== |
4. 我们知道ArrayList是线程不安全,请编写一个不安全的案例并给出解决方案
HashSet与ArrayList一致 HashMap
HashSet底层是一个HashMap,存储的值放在HashMap的key里,value存储了一个PRESENT的静态Object对象
故障现象
1
2
3
4
5
6
7
8
9
10
11
12public class ContainerDemo {
public static void main(String[] args) {
List<Integer> list = new ArrayList<>();
Random random = new Random();
for (int i = 0; i < 100; i++) {
new Thread(() -> {
list.add(random.nextInt(10));
System.out.println(list);
}).start();
}
}
}发现报
java.util.ConcurrentModificationException导致原因
- 并发修改导致的异常
解决方案
new Vector();Collections.synchronizedList(new ArrayList<>());new CopyOnWriteArrayList<>();
优化建议
- 在读多写少的时候推荐使用 CopeOnWriteArrayList 这个类
5. 公平锁/非公平锁/可重入锁/递归锁/自旋锁谈谈你的理解?请手写一个自旋锁
5.1 公平锁和非公平锁
是什么
公平锁:是指多个线程按照申请的顺序来获取值
非公平锁:是值多个线程获取值的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程优先获取锁,在高并发的情况下,可能会造成优先级翻转或者饥饿现象
两者区别
- 公平锁:在并发环境中,每一个线程在获取锁时会先查看此锁维护的等待队列,如果为空,或者当前线程是等待队列的第一个就占有锁,否者就会加入到等待队列中,以后会按照 FIFO 的规则获取锁
- 非公平锁:一上来就尝试占有锁,如果失败在进行排队
题外话
- Java ReentrantLock而言,通过构造哈数指定该锁是否是公平锁 默认是非公平锁 非公平锁的优点在于吞吐量必公平锁大.
- 对于synchronized而言 也是一种非公平锁.
5.2 可重入锁(又名递归锁)
- 是什么
- 可重入锁:指的是同一个线程外层函数获得锁之后,内层仍然能获取到该锁,在同一个线程在外层方法获取锁的时候,在进入内层方法或会自动获取该锁
- 不可重入锁: 所谓不可重入锁,即若当前线程执行某个方法已经获取了该锁,那么在方法中尝试再次获取锁时,就会获取不到被阻塞
- ReentrantLock/synchronized就是一个典型的可重入锁
- 可重入锁最大的作用就是避免死锁
代码实例
1 | //synchronized可重入 |
1 | //ReentrantLock可重入 |
5.3 自旋锁
- 是指定尝试获取锁的线程不会立即堵塞,而是采用循环的方式去尝试获取锁,这样的好处是减少线程上线文切换的消耗,缺点就是循环会消耗 CPU。

- 手动实现自旋锁
1 | public class SpinLock { |
输出:
1 | Thread[Thread-0,5,main] coming... |
获取锁的时候,如果原子引用为空就获取锁,不为空表示有人获取了锁,就循环等待。
5.4 独占锁(写)/共享锁(读)/互斥锁
是什么
- 独占锁:指该锁一次只能被一个线程持有
- 共享锁:该锁可以被多个线程持有
对于 ReentrantLock 和 synchronized 都是独占锁;对与 ReentrantReadWriteLock 其读锁是共享锁而写锁是独占锁。读锁的共享可保证并发读是非常高效的,读写、写读和写写的过程是互斥的。
读写锁例子
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40public class MyCache {
private volatile Map<String, Object> map = new HashMap<>();
private ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
WriteLock writeLock = lock.writeLock();
ReadLock readLock = lock.readLock();
public void put(String key, Object value) {
try {
writeLock.lock();
System.out.println(Thread.currentThread().getName() + " 正在写入...");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
map.put(key, value);
System.out.println(Thread.currentThread().getName() + " 写入完成,写入结果是 " + value);
} finally {
writeLock.unlock();
}
}
public void get(String key) {
try {
readLock.lock();
System.out.println(Thread.currentThread().getName() + " 正在读...");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Object res = map.get(key);
System.out.println(Thread.currentThread().getName() + " 读取完成,读取结果是 " + res);
} finally {
readLock.unlock();
}
}
}- 测试
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19public class ReadWriteLockDemo {
public static void main(String[] args) {
MyCache cache = new MyCache();
for (int i = 0; i < 5; i++) {
final int temp = i;
new Thread(() -> {
cache.put(temp + "", temp + "");
}).start();
}
for (int i = 0; i < 5; i++) {
final int temp = i;
new Thread(() -> {
cache.get(temp + "");
}).start();
}
}
}- 输出结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20Thread-0 正在写入...
Thread-0 写入完成,写入结果是 0
Thread-1 正在写入...
Thread-1 写入完成,写入结果是 1
Thread-2 正在写入...
Thread-2 写入完成,写入结果是 2
Thread-3 正在写入...
Thread-3 写入完成,写入结果是 3
Thread-4 正在写入...
Thread-4 写入完成,写入结果是 4
Thread-5 正在读...
Thread-7 正在读...
Thread-8 正在读...
Thread-6 正在读...
Thread-9 正在读...
Thread-5 读取完成,读取结果是 0
Thread-7 读取完成,读取结果是 2
Thread-8 读取完成,读取结果是 3
Thread-6 读取完成,读取结果是 1
Thread-9 读取完成,读取结果是 4能保证读写、写读和写写的过程是互斥的时候是独享的,读读的时候是共享的。
写操作 原子+独占 整个过程必须是一个完成的统一整体 中间不允许被分割 被打断
6.CountDownLatch/CyclicBarrier/Semaphore使用过吗?
6.1 CountDownLatch
让一些线程堵塞直到另一个线程完成一系列操作后才被唤醒。CountDownLatch 主要有两个方法,当一个或多个线程调用 await 方法时,调用线程会被堵塞,其他线程调用 countDown 方法会将计数减一(调用 countDown 方法的线程不会堵塞),当计数其值变为零时,因调用 await 方法被堵塞的线程会被唤醒,继续执行。
示例一:假设我们有这么一个场景,教室里有班长和其他6个人在教室上自习,怎么保证班长等其他6个人都走出教室在把教室门给关掉。
1 | public class CountDownLanchDemo { |
此时输出
1 | 0 离开了教室... |
发现班长都没有等其他人理他教室就把门给关了,此时我们就可以使用 CountDownLatch 来控制
1 | public class CountDownLanchDemo { |
此时输出
1 | 0 离开了教室... |
示例二:枚举的使用–秦灭六国
1 | /** |
6.2 CyclicBarrier
可循环(Cyclic)使用的屏障。让一组线程到达一个屏障(也可叫同步点)时被阻塞,知道最后一个线程到达屏障时,屏障才会开门,所有被屏障拦截的线程才会继续干活,线程进入屏障通过CycliBarrier的await()方法
- 代码示例:
1 | import java.util.concurrent.BrokenBarrierException; |
6.3 Semaphore信号量
信号量主要用于两个目的,一个是用于多个共享资源的互斥作用,另一个用于并发线程数的控制
可以代替Synchronize和Lock
抢车位代码示例:
1 | import java.util.concurrent.Semaphore; |
7. 阻塞队列知道吗?
7.1队列+阻塞队列
阻塞队列,顾名思义,首先它是一个队列,而一个阻塞队列在数据结构中所起的作用大致如图所示:

线程1往阻塞队列中添加元素二线程2从队列中移除元素
- 当阻塞队列是空时,从队列中获取元素的操作将会被阻塞.
- 当阻塞队列是满时,往队列中添加元素的操作将会被阻塞.
- 同样试图往已满的阻塞队列中添加新圆度的线程同样也会被阻塞,直到其他线程从队列中移除一个或者多个元素或者全清空队列后使队列重新变得空闲起来并后续新增.
7.2 为什么用?有什么好处?
在多线程领域:所谓阻塞,在某些情况下会挂起线程(即线程阻塞),一旦条件满足,被挂起的线程优惠被自动唤醒
为什么需要使用BlockingQueue
好处是我们不需要关心什么时候需要阻塞线程,什么时候需要唤醒线程,因为BlockingQueue都一手给你包办好了
在concurrent包 发布以前,在多线程环境下,我们每个程序员都必须自己去控制这些细节,尤其还要兼顾效率和线程安全,而这会给我们的程序带来不小的复杂度.
7.3 BlockingQueue的核心方法
| 方法类型 | 抛出异常 | 特殊值 | 阻塞 | 超时 |
|---|---|---|---|---|
| 插入 | add(e) | offer(e) | put(e) | offer(e,time,unit) |
| 移除 | remove() | poll() | take | poll(time,unit) |
| 检查 | element() | peek() | 不可用 | 不可用 |
| 方法类型 | status |
|---|---|
| 抛出异常 | 当阻塞队列满时,再往队列中add会抛IllegalStateException: Queue full当阻塞队列空时,在网队列里remove会抛 NoSuchElementException |
| 特殊值 | 插入方法,成功true失败false 移除方法,成功返回出队列的元素,队列里没有就返回null |
| 一直阻塞 | 当阻塞队列满时,生产者线程继续往队列里put元素,队列会一直阻塞线程知道put数据或响应中断退出 当阻塞队列空时,消费者线程试图从队列take元素,队列会一直阻塞消费者线程知道队列可用。 |
| 超时退出 | 当阻塞队列满时,队列会阻塞生产者线程一定时间,超过限时后生产者线程会退出 |
7.4 架构梳理+种类分析
种类分析
- ArrayBlockingQueue:由数据结构组成的有界阻塞队列。
- LinkedBlockingQueue:由链表结构组成的有界(但大小默认值为
Integer.MAX_VALUE)阻塞队列。 - PriorityBlockingQueue:支持优先级排序的无界阻塞队列。
- DelayQueue:使用优先级队列实现的延迟无界阻塞队列。
- SychronousQueue:不存储元素的阻塞队列,也即单个元素的队列。
- LinkedTransferQueue:由链表结构组成的无界阻塞队列。
- LinkedBlockingDeque:由历览表结构组成的双向阻塞队列。
SychronousQueue
理论:SynchronousQueue没有容量,与其他BlockingQueue不同,SychronousQueue是一个不存储元素的BlockingQueue,每一个put操作必须要等待一个take操作,否则不能继续添加元素,反之亦然。
代码示例
1 | import java.util.concurrent.BlockingQueue; |
7.5使用场景
- 线程池
- 消息中间件
- 生产者消费者模式
传统版生产者消费者模式
1 | /** |
阻塞队列版生产者消费者模式
1 | class MyResource { |
8. 线程池用过吗?ThreadPoolExecutor谈谈你的理解?
8.1 为什么使用线程池,优势
线程池用于多线程处理中,它可以根据系统的情况,可以有效控制线程执行的数量,优化运行效果。线程池做的工作主要是控制运行的线程的数量,处理过程中将任务放入队列,然后在线程创建后启动这些任务,如果线程数量超过了最大数量,那么超出数量的线程排队等候,等其它线程执行完毕,再从队列中取出任务来执行。
主要特点为:
- 线程复用
- 控制最大并发数量
- 管理线程
主要优点
降低资源消耗,通过重复利用已创建的线程来降低线程创建和销毁造成的消耗。
提高相应速度,当任务到达时,任务可以不需要的等到线程创建就能立即执行。
提高线程的可管理性,线程是稀缺资源,如果无限制的创建,不仅仅会消耗系统资源,还会降低体统的稳定性,使用线程可以进行统一分配,调优和监控。
创建线程的几种方式
继承 Thread
实现 Runnable 接口
实现 Callable
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16public class CallableDemo {
public static void main(String[] args) throws ExecutionException, InterruptedException {
// 在 FutureTask 中传入 Callable 的实现类
FutureTask<Integer> futureTask = new FutureTask<>(new Callable<Integer>() {
public Integer call() throws Exception {
return 666;
}
});
// 把 futureTask 放入线程中
new Thread(futureTask).start();
// 获取结果
Integer res = futureTask.get();
System.out.println(res);
}
}
8.2 线程池如何使用?
8.2.1架构实现

8.2.2 编码实现
1 | import java.util.concurrent.*; |
**Executors.newSingleThreadExecutor()**:只有一个线程的线程池,因此所有提交的任务是顺序执行
**Executors.newCachedThreadPool()**:线程池里有很多线程需要同时执行,老的可用线程将被新的任务触发重新执行,如果线程超过60秒内没执行,那么将被终止并从池中删除
**Executors.newFixedThreadPool()**:拥有固定线程数的线程池,如果没有任务执行,那么线程会一直等待
Executors.newScheduledThreadPool():用来调度即将执行的任务的线程池
Executors.newWorkStealingPool(): newWorkStealingPool适合使用在很耗时的操作,但是newWorkStealingPool不是ThreadPoolExecutor的扩展,它是新的线程池类ForkJoinPool的扩展,但是都是在统一的一个Executors类中实现,由于能够合理的使用CPU进行对任务操作(并行操作),所以适合使用在很耗时的任务中
详细解释
- **Executors.newSingleThreadExecutor()**:

主要特点如下:
创建一个单线程化的线程池,它只会用唯一的工作线程来执行任务,保证所有任务都按照指定顺序执行.
newSingleThreadExecutor将corePoolSize和MaxmumPoolSize都设置为1,它使用的的LinkedBlockingQueue
- **Executors.newCachedThreadPool()**:

主要特点如下:
创建一个可缓存线程池,如果线程池长度超过处理需要,可灵活回收空闲线程,若无可回收,则创建新线程.
newCachedThreadPool将corePoolSize设置为0MaxmumPoolSize设置为Integer.MAX_VALUE,它使用的是SynchronousQUeue,也就是说来了任务就创建线程运行,如果线程空闲超过60秒,就销毁线程
- **Executors.newFixedThreadPool()**:

主要特点如下:
1.创建一个定长线程池,可控制线程的最大并发数,超出的线程会在队列中等待.
2.newFixedThreadPool创建的线程池corePoolSize和MaxmumPoolSize是 相等的,它使用的的LinkedBlockingQueue
8.2.3 ThreadPoolExecutor
ThreadPoolExecutor作为java.util.concurrent包对外提供基础实现,以内部线程池的形式对外提供管理任务执行,线程调度,线程池管理等等服务。

8.3 线程池几个重要参数介绍?

- corePoolSize:线程池中的常驻核心线程数:
- 在创建了线程池后,当有请求任务来之后,就会安排池中的线程去执行请求任务,近视理解为今日当值线程
- 当线程池中的线程数目达到corePoolSize后,就会把到达的任务放入到缓存队列当中.
- keepAliveTime
- 默认情况下:只有当线程池中的线程数大于corePoolSize时keepAliveTime才会起作用,知道线程中的线程数不大于corepoolSIze,
| 参数 | 作用 |
|---|---|
| corePoolSize | 核心线程池大小 |
| maximumPoolSize | 最大线程池大小 |
| keepAliveTime | 线程池中超过 corePoolSize 数目的空闲线程最大存活时间;可以allowCoreThreadTimeOut(true) 使得核心线程有效时间 |
| TimeUnit | keepAliveTime 时间单位 |
| workQueue | 阻塞任务队列 |
| threadFactory | 新建线程工厂 |
| RejectedExecutionHandler | 当提交任务数超过 maxmumPoolSize+workQueue 之和时,任务会交给RejectedExecutionHandler 来处理 |
8.4 说说线程池的底层工作原理?

在创建了线程池之后,等待提交过来的 人物请求。
当调用execute()方法添加一个请求任务时,线程池会做出如下判断
2.1 如果正在运行的线程数量小于corePoolSize,那么马上船舰线程运行这个任务;
2.2 如果正在运行的线程数量大于或等于corePoolSize,那么将这个任务放入队列;
2.3如果此时队列满了且运行的线程数小于maximumPoolSize,那么还是要创建非核心线程立刻运行此任务
2.4如果队列满了且正在运行的线程数量大于或等于maxmumPoolSize,那么启动饱和拒绝策略来执行
当一个线程完成任务时,他会从队列中却下一个任务来执行
当一个线程无事可做超过一定的时间(keepAliveTime)时,线程池会判断:
如果当前运行的线程数大于corePoolSize,那么这个线程会被停掉;所以线程池的所有任务完成后他最大会收缩到corePoolSize的大小
9. 线程池用过吗?生产上你是如何设置合理参数
9.1 线程池的拒绝策略请你谈谈
- 是什么
- 等待队列已经满了,再也塞不下新的任务,同时线程池中的线程数达到了最大线程数,无法继续为新任务服务。
- 拒绝策略
- AbortPolicy(默认):处理程序遭到拒绝将抛出运行时 RejectedExecutionException
- CallerRunsPolicy:线程调用运行该任务的 execute 本身。此策略提供简单的反馈控制机制,能够减缓新任务的提交速度。
- DiscardPolicy:直接丢弃任务,不予任何处理也不抛出异常.如果允许任务丢失,这是最好的拒绝策略
- DiscardOldestPolicy:如果执行程序尚未关闭,则位于工作队列头部的任务将被删除,然后重试执行程序(如果再次失败,则重复此过程)
JDK内置的拒绝策略
以上内置策略均实现了RejectExecutionHandler接口
9.2 你在工作中单一的/固定数的/可变你的三种创建线程池的方法,你用哪个多?超级大坑
如果读者对Java中的阻塞队列有所了解的话,看到这里或许就能够明白原因了。
Java中的BlockingQueue主要有两种实现,分别是ArrayBlockingQueue 和 LinkedBlockingQueue。
ArrayBlockingQueue是一个用数组实现的有界阻塞队列,必须设置容量。
LinkedBlockingQueue是一个用链表实现的有界阻塞队列,容量可以选择进行设置,不设置的话,将是一个无边界的阻塞队列,最大长度为Integer.MAX_VALUE。
这里的问题就出在:不设置的话,将是一个无边界的阻塞队列,最大长度为Integer.MAX_VALUE。也就是说,如果我们不设置LinkedBlockingQueue的容量的话,其默认容量将会是Integer.MAX_VALUE。
而newFixedThreadPool中创建LinkedBlockingQueue时,并未指定容量。此时,LinkedBlockingQueue就是一个无边界队列,对于一个无边界队列来说,是可以不断的向队列中加入任务的,这种情况下就有可能因为任务过多而导致内存溢出问题。
上面提到的问题主要体现在newFixedThreadPool和newSingleThreadExecutor两个工厂方法上,并不是说newCachedThreadPool和newScheduledThreadPool这两个方法就安全了,这两种方式创建的最大线程数可能是Integer.MAX_VALUE,而创建这么多线程,必然就有可能导致OOM。

9.3 你在工作中是如何创建线程池的,是否自定义过线程池使用
1 | public static void main(String[] args) { |
9.4 合理配置线程池你是如何考虑的?
CPU 密集型
- CPU 密集的意思是该任务需要大量的运算,而没有阻塞,CPU 一直全速运行。
- CPU 密集型任务尽可能的少的线程数量,一般为 CPU 核数 + 1 个线程的线程池。
IO 密集型
由于 IO 密集型任务线程并不是一直在执行任务,可以多分配一点线程数,如 CPU * 2 。
IO密集型,即该任务需要大量的IO,即大量的阻塞。
在单线程上运行IO密集型的任务会导致浪费大量的 CPU运算能力浪费在等待。
所以在IO密集型任务中使用多线程可以大大的加速程序运行,即使在单核CPU上,这种加速主要就是利用了被浪费掉的阻塞时间。
IO密集型时,大部分线程都阻塞,故需要多配置线程数:
参考公式:==CPU核数/(1-阻塞系数) 阻塞系数在0.8~0.9之间==
八核CPU:8/(1-0,9)=80
10. 死锁编码及定位分析
10.1 是什么
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那他们都将无法推进下去,如果系统资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁。

产生死锁的主要原因
- 系统资源不足
- 进程运行推进的顺序不合适
- 资源分配不当
10.2 代码
1 | import java.util.concurrent.TimeUnit; |
10.3 解决
解决
jps -l 命令查定位进程号
1
2
3
4
528519 org.jetbrains.jps.cmdline.Launcher
32376 com.intellij.idea.Main
28521 com.zzxx.thread.DeadLockDemo
27836 org.jetbrains.kotlin.daemon.KotlinCompileDaemon
28591 sun.tools.jps.Jpsjstack 28521 找到死锁查看
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
372019-05-07 00:04:15
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode):
"Attach Listener" #13 daemon prio=9 os_prio=0 tid=0x00007f7acc001000 nid=0x702a waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
// ...
Found one Java-level deadlock:
=============================
"pool-1-thread-2":
waiting to lock monitor 0x00007f7ad4006478 (object 0x00000000d71f60b0, a java.lang.String),
which is held by "pool-1-thread-1"
"pool-1-thread-1":
waiting to lock monitor 0x00007f7ad4003be8 (object 0x00000000d71f60e8, a java.lang.String),
which is held by "pool-1-thread-2"
Java stack information for the threads listed above:
===================================================
"pool-1-thread-2":
at com.cuzz.thread.DeadLockDemo.method(DeadLockDemo.java:34)
- waiting to lock <0x00000000d71f60b0> (a java.lang.String)
- locked <0x00000000d71f60e8> (a java.lang.String)
at com.cuzz.thread.DeadLockDemo.lambda$main$1(DeadLockDemo.java:21)
at com.cuzz.thread.DeadLockDemo$$Lambda$2/2074407503.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"pool-1-thread-1":
at com.cuzz.thread.DeadLockDemo.method(DeadLockDemo.java:34)
- waiting to lock <0x00000000d71f60e8> (a java.lang.String)
- locked <0x00000000d71f60b0> (a java.lang.String)
at com.cuzz.thread.DeadLockDemo.lambda$main$0(DeadLockDemo.java:20)
at com.cuzz.thread.DeadLockDemo$$Lambda$1/558638686.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Found 1 deadlock.最后发现一个死锁。



