JUC面试点汇总

我们会在这里介绍我所涉及到的JUC相关的面试点内容，本篇内容持续更新

我们会介绍下述JUC的相关面试点：

线程状态
线程池
Wait和Sleep
Synchronized和Lock
Volatile线程安全
悲观锁和乐观锁
Hashtable和ConcurrentHashMap
ThreadLocal

线程状态

下面我们来介绍我们面试中经常考察的两种线程状态分类

六种线程状态

Java虚拟机将线程状态划分为六种：

我们来简单介绍一下：

NEW 线程刚被创建，但是还没有调用 start() 方法
RUNNABLE 当调用了 start() 方法之后
注意，Java API 层面的 RUNNABLE 状态涵盖了操作系统层面的可运行状态运行状态和阻塞状态
BLOCKED ， WAITING ， TIMED_WAITING 都是 Java API 层面对阻塞状态的细分
BLOCKED 表示被锁拦截下的阻塞
WAITING 表示自己进行wait等待时的阻塞
TIMED_WAITING 表示进行有时间限制的阻塞
TERMINATED 当线程代码运行结束

五种线程状态

操作系统将线程分为五种状态：

我们来简单介绍一下：

【初始状态】仅是在语言层面创建了线程对象，还未与操作系统线程关联
【可运行状态】（就绪状态）指该线程已经被创建（与操作系统线程关联），可以由 CPU 调度执行
【运行状态】指获取了 CPU 时间片运行中的状态
- 当 CPU 时间片用完，会从【运行状态】转换至【可运行状态】，会导致线程的上下文切换
【阻塞状态】
- 如果调用了阻塞 API，如 BIO 读写文件，这时该线程实际不会用到 CPU，会导致线程上下文切换，进入【阻塞状态】
- 等 BIO 操作完毕，会由操作系统唤醒阻塞的线程，转换至【可运行状态】
- 与【可运行状态】的区别是，对【阻塞状态】的线程来说只要它们一直不唤醒，调度器就一直不会考虑调度它们
【终止状态】表示线程已经执行完毕，生命周期已经结束，不会再转换为其它状态

线程池

下面我们来介绍线程池中常考的一些知识点

线程池工作流程图

首先我们给出线程池的工作流程图以及相关参数：

我们对上面元素进行简单介绍：

submit(task):负责分配任务，将任务传入WorkQueue
WorkQueue:工作等待队列，用于存放未被执行的任务，通常具有任务个数限制，防止内存过满
核心线程：一直处于运行状态的线程，不断从WorkQueue中取得任务并执行
救济线程：只有当核心线程全部运行且WorkQueue装载满员并且有submit继续传入任务时开启，在一定时间没有任务接收后结束

线程池工作参数

我们给出线程池工作的基本参数：

/*corePoolSize核心线程数目*/

用于控制核心线程的个数

/*maximumPoolSize最大线程数目*/

表示核心线程和救急线程的最大个数，用该值减去corePoolSize核心线程数目就是救急线程个数

/*keepAliveTime生存时间*/

针对救急线程，当救急线程在该时间段没有接收新任务，就结束该线程

/*unit时间单位*/

配合keepAliveTime生存时间使用的时间单位

/*workQueue阻塞队列*/

用于存放处于阻塞状态的任务

/*threadFactory线程工厂*/

用于生成线程名称

/*handler拒绝策略*/

当线程均处于运行状态，workQueue满员，且有新任务进入时，handler负责处理新进入的线程

- AbortPolicy 让调用者抛出 RejectedExecutionException 异常，这是默认策略

- CallerRunsPolicy 让调用者运行任务

- DiscardPolicy 放弃本次任务

- DiscardOldestPolicy 放弃队列中最早的任务，本任务取而代之

- Dubbo 的实现，在抛出 RejectedExecutionException 异常之前会记录日志，并 dump 线程栈信息，方 便定位问题

- Netty 的实现，是创建一个新线程来执行任务

- ActiveMQ 的实现，带超时等待（60s）尝试放入队列，类似我们之前自定义的拒绝策略

- PinPoint 的实现，它使用了一个拒绝策略链，会逐一尝试策略链中每种拒绝策略

线程池构建代码

我们直接给出线程池构建代码，了解即可：

/*线程池构造：我之前有线程池专门的文章，可以深入了解*/

public ThreadPoolExecutor(int corePoolSize,

                          int maximumPoolSize,

                          long keepAliveTime,

                          TimeUnit unit,

                          BlockingQueue<Runnable> workQueue,

                          ThreadFactory threadFactory,

                          RejectedExecutionHandler handler)

Wait和Sleep

我们来介绍一下wait和sleep的相关面试点

Wait和Sleep区别以及共同点

我们给出wait和sleep的区别以及共同点：

/*共同点*/

wait(),wait(long),sleep(long) 都会导致阻塞，将当前线程暂时放弃CPU使用权

/*不同点*/

// 方法归属类不同

wait 	属于	Object实体类

sleep 	属于	Thread线程类

// 醒来时机不同

wait()：			只有当notify唤醒时才会醒来

wait(long): 	当时间结束，或者notify唤醒就会醒来

sleep(long):	当时间结束才会醒来

注意：都可以被打断唤醒！

// 锁性质不同

1.wait必须配合锁一同使用，且只有锁对象调用Lock.lock；sleep在任何时间段都可以使用

2.wait在lock时会解除当前锁的限制；sleep若在锁中不会解除当前锁的限制

Synchronized和Lock

我们来介绍一下Synchronized和Lock的相关面试点

Synchronized和Lock区别以及共同点

我们会从三个层面讲解两者的区别以及共同点：

/*语法层面*/

// 所属类

synchronized：关键字，属于JVM，用C++语言实现

Lock：接口，属于JDK，用Java语言实现

// 锁实现

synchronized：在结束同步代码块后自动释放锁

Lock：在结束代码块后，需要手动unlock释放锁

/*功能层面*/

// 相同点

均属于悲观锁，具备互斥，同步，锁重入功能

// 不同点

Lock提供了synchronized所不具备的功能：获得等待状态，公平锁，可打断，可超时，多条件变量

Lock提供了多场景Lock：ReentrantLock，ReentrantReadWriteLock

/*性能方面*/

// 性能差距

synchronized：在无竞争情况下，存在轻量级锁，偏向锁，性能较高

Lock：在竞争激烈的情况下，性能更好

Volatile线程安全

我们来介绍一下Volatile的线程安全相关问题

Volatile线程安全

我们首先要知道线程安全主要从三方面解释：

/*可见性*/

当前线程对数值的修改是否对其他线程可见？

问题产生原因：

    CPU和内存之间还有一层缓存区，当使用数据较多时，会直接将内存的数据放入缓存区，然后直接从缓存区调入数据

    这时倘若另一个线程修改了内存中的数据，但是原线程仍旧从自己的缓存区读取数据，就会导致数据不可见

/*有序性*/

当前线程内的代码是否按照编写顺序执行？

问题产生原因：

    JVM存在自动编写机制，当出现同级别的代码时，JVM会自动优化代码顺序，加快速度，可能导致代码执行顺序错乱

/*原子性*/

当前线程内的代码是否为一次执行？

问题产生原因：

    线程是由CPU调度使用的，倘若线程调度到达指定时间片，可能就会导致线程内代码未完成执行而被其他线程使用的情况

然后我们需要知道Volatile对这三种特性的可控度：

/*可见性*/

Volatile可以保证数据的可见性

Volatile会使该属性的每次读取都默认从内存中读取（该属性不会被存放于缓冲区）

/*有序性*/

Volatile可以保证数据的有序性

Volatile存在写屏障和读屏障

    写屏障出现在属性输入之后，在写屏障之前的代码顺序不会变更

    读屏障出现在属性读取之前，在读屏障之后的代码顺序不会变更

/*原子性*/

Volatile无法保证数据的原子性！

悲观锁和乐观锁

我们来介绍一下悲观锁和乐观锁的面试点

悲观锁和乐观锁区别

我们来介绍一下悲观锁和乐观锁的区别：

/*悲观锁*/

代表：

    Synchronized

    Lock

特点：

    1.核心思想：当前线程占用锁后，才能操作共享数据，只有当当前线程结束操作后，其他线程才能竞争

    2.线程的运行与阻塞都会导致上下文切换，频繁的上下文切换会导致CPU速度降低

    3.悲观锁大部分都存在自旋现象，在获得锁时会多次尝试来减少上下文切换次数

/*乐观锁*/

代表：

    Atomic系列

    AtomicInteger

特点：

	1.核心思想：所有数据都可以操作共享数据，但只有一个线程可以修改数据，其他线程如果修改失败就会不断尝试

    2.由于线程一直运行，不需要阻塞，不涉及上下文切换

    3.由于线程一直运行，需要一个CPU保证其线程的活动，否则单CPU下乐观锁属于负增益，一般线程数不会超过CPU个数

悲观锁乐观锁代码比较

我们分别给出悲观锁和乐观锁的代码展示：

/*乐观锁底层实现*/

// 乐观锁底层其实是采用Unsafe类来完成的

// 1.获得该类的属性对于类的偏移量(第一个参数：类名称.class，第二个参数：类属性名称)

Long BALANCE = unsafe.objectFieldOffset(Account.class,"blance");

// 2.采用unsafe的原子比较赋值方法(第一个参数：类对象，第二个参数：属性偏移量，第三个参数：修改前数值，第四个参数：修改后数值)

// 如果再次检测时，该值和oldInt相同，就将其修改为newInt，否则不作为

unsafe.compareAndSetInt(account,BALANCE,oldInt,newInt);

/*乐观锁代码*/

Thread t1 = new Thread(() -> {

    // 乐观锁需要不断尝试

    while(true){

        // 每次获得当前值

        int oldInt = account.getBalance;

        // 我们假设做++操作

        int newInt = oldInt + 1;

        // 然后启动unsafe的比较赋值(compareAndSetInt会返回一个布尔值表示是否成功)，若成功退出循环

        if(unsafe.compareAndSetInt(account,BALANCE,oldInt,newInt)){

            break;

        }

    }

}).start;

/*悲观锁代码*/

Thread t2 = new Thread(() -> {

    // 悲观锁就是直接采用锁处理即可

    synchronized(Account.class){

        int oldInt = account.getBalance;

        int newInt = oldInt + 1;

        account.setBalance(newInt);

    }

})

Hashtable和ConcurrentHashmap

我们来介绍一下Hashtable和ConcurrentHashmap的面试点

Hashtable和ConcurrentHashmap区别

我们来介绍一下Hashtable和ConcurrentHashmap区别：

/*线程安全？*/

Hashtable和ConcurrentHashMap均属于线程安全类的Map集合

/*并发度*/

Hashtable：只存在一个锁，所有索引点的操作均在一个锁上，并发度低

1.7ConcurrentHashMap：底层由数组+Segment+链表结构，每个Segment对应一把锁，不同Segment不会造成锁冲突

1.8ConcurrentHashMap：底层由数组+链表结构，每个链表头对应一把锁，相当于每个索引点对应一把锁，只有同一条链表会产生锁冲突

Hashtable

我们来介绍一下Hashtable的基本面试点：

/*基本问题*/

初始capacity：11

扩容：超过0.75

索引：hashcode即可，（因为以质数为主，分散性较好，不需要二次hash）

1.7ConcurrentHashMap

我们来介绍一下JDK1.7版本的ConcurrentHashMap：

/*基本组成*/

capacity：总共的索引头

factor：超过0.75

clevel：并发度，也就是Segment的个数

每个Segment算是一个大桶，然后大桶中会根据capacity/clevel算出小桶

举例：

    capacity：32

    factor：0.75

    clevel：8

    这时存在8个Segment，每个Segment中存有四个初始小桶

    不同Segment拥有不同锁，不同Segment独自占有并发性

    基本形式如下：

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

/*put操作*/

1.hashCode

2.hash

3.根据hash值二进制的前（clevel二进制为2的n次方）n位的数值来判断放在哪个大桶

4.根据hash值二进制的后（小桶大小二进制为2的n次方）n为的数值来判断放哪个大桶

举例：

    capacity：32

    factor：0.75

    clevel：8

    首先clevel的为2的3次方，小桶大小为2的2次方

    假设我们的hash值二进制为 110 1101 0110

    这时我们的大桶取前三位：110 -> 6 -> Segment[6]

    这时我们的小桶取后两位： 10 -> 2 -> Segment[6][2]

    也就是第七个桶的第三个位置

/*扩容*/

扩容仅针对每个Segment单独扩容，最开始的桶大小为capacity/clevel，当超过factor，就会自动扩大一倍，单独计算

Segment[0]的扩容不会影响到其他Segment的桶大小

/*Segment[0]*/

Segment[0]会自动初始化小桶，其他Segment只有在put第一个数时初始化

因为Segment[0]类似于一个初始模板，其他Segment会根据Segment[0]的大小来构造，节省空间（懒汉式构建）

1.8ConcurrentHashMap

我们来介绍一下JDK1.8版本的ConcurrentHashMap：

/*基本知识点*/

1.8版本的ConcurrentHashMap只包含 数组 + 链表 结构

属于懒汉式初始化，我们new一个ConcurrentHashMap并不会产生数组，只有开始put时才会初始化

capacity：16

	注意：这里的capacity并不是初始桶大小，而是我们需要插入的数的数量，系统会根据我们书写的capacity更换桶大小

    例如我们写15，系统会为我们分配一个大小为32的桶

factor：达到0.75

/*并发依据*/

1.8ConcurrentHashMap根据链表头分配不同的锁，也就是如果不是在同一索引下，均可以正常运行

/*扩容操作*/

扩容是ConcurrentHashMap的考点之一

ConcurrenthashMap扩容是从后往前移动数据，每次移动完成该索引点数据，就为其标记为ForwardingNode用来表示已移动

ConcurrentHashMap扩容不再是将原数据next更换，而是直接在新数组上创建新数据，将数据拷贝过去，防止并发操作时出现问题

/*扩容细节*/

当一个线程t1正在进行扩容，另一个线程t2参与该HashMap各项操作：

1.get操作：

	I.如果查询的该索引属于ForwardingNode，就去新的数组中查找

    II.如果查询的索引不属于ForwardingNode，就直接查找

2.put操作：

    I.如果该索引不属于ForwardingNode，就直接插入即可

    II.如果该索引正在迁移，堵塞

    III.如果该索引已经属于ForwardingNode，帮助线程t1完成扩容后，再进行修改

ThreadLocal

我们来介绍一下ThreadLocal的面试点

对ThreadLocal的理解

我们来讲解一下对对ThreadLocal的理解：

/*线程安全性*/

ThreadLocal可以实现资源对象的线程隔离，让每个线程各用各的资源对象，避免争用引发的线程安全问题

ThreadLocal同时实现了线程内资源共享

/*ThreadLocal使用*/

每个线程中有一个ThreadLocalMap类型的成员变量，用于存储资源对象

1.创建一个ThreadLocal（该ThreadLocal实际上就是ThreadLocalMap的key）

    ThreadLocal<class?> t1 = new ThreadLocal<>();

2.可以调用set方法存储数据（ThreadLocal就是key，资源对象作为value，放入当前线程的ThreadLocalMap集合中）

	t1.set(new String("123"));

3.可以调用get方法查找数据（根据ThreadLocal为key，查找相关数据）

    t1.get();

4.可以调用remove方法删除该数据（根据ThreadLocal为key，删除相关数据）

注意点：

    I.当使用set时才会构造map对象

    II.不同的ThreadLocal使用不同的数据结构

    III.扩容时阈值为0.75，每次扩容一倍；存储时采用开放寻址法

/*key*/

这里的key采用的是弱引用：

    1.Thread可能需要长时间运行（如线程池的线程），如果key不再被使用，可以被JVM的GC所释放

    2.GC仅使key释放，但是value不会释放：

    	I.获得key时，会删除value

  		II.setkey时，会将附近的value删除

    	III.手动remove删除

结束语

目前关于JUC的面试点就总结到这里，该篇文章后续会持续更新~

附录

参考资料：

黑马Java八股文面试题视频教程：并发篇-01-线程状态_java中的线程状态_哔哩哔哩_bilibili