面经——多线程

最新推荐文章于 2023-09-08 10:00:25 发布

Lumos`

最新推荐文章于 2023-09-08 10:00:25 发布

阅读量541

点赞数 1

分类专栏： Java多线程

本文链接：https://blog.csdn.net/weixin_41910694/article/details/103553848

版权

Java多线程专栏收录该内容

27 篇文章 0 订阅

订阅专栏

面经——多线程

创建线程和终止线程方式
Runnable和callable区别
synchronize问题详解
乐观锁和悲观锁
线程安全和非线程安全区别
JMM 内存模型
volatile解析
公平锁和非公平锁区别？为什么公平锁效率低？
锁优化（自旋锁、自适应自旋锁、锁消除、锁粗化、偏向锁、轻量级锁、重量级锁解释）
AQS原理及应用
CAS
线程同步方法
ThreadLocal原理
ReenTrantLock原理
线程状态，start,run,wait,notify,yiled,sleep,join等方法的作用以及区别
关于 Atomic 原子类
线程池相关
手写简单的线程池，体现线程复用
手写消费者生产者模式
手写阻塞队列
手写多线程交替打印ABC

注：题目从牛客 Java部门面经整理而来。
2020秋招面经大汇总！（岗位划分）
在这里插入图片描述

1. 创建线程和终止线程方式

创建线程有四种方式：

继承Thread 重写 run 方法。
实现 Runnable 接口。
实现 Callable 接口。
使用Executor框架来创建线程池

中断线程方式：

new Thread().isInterrupted() 方法用于获取当前线程的中断状态
new Thread().interrupted() 方法用于设置当前线程的中断状态，即中断当前线程
Thread.interrupted()用于获取当前线程的中断状态，同时还会重置中断状态

2. Runnable和callable区别

Runnable 没有返回值，Callable 可以拿到有返回值，Callable 可以看作是 Runnable 的补充。
Callable接口的call()方法允许抛出异常；Runnable的run()方法异常只能在内部消化，不能往上继续抛

3. synchronize问题详解

synchronized 问题新开了一遍笔记：synchronized面试五连击
在这里插入图片描述

4. 乐观锁和悲观锁

1. 乐观锁和悲观锁区别

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁：总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

2. 两种锁的使用场景
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

5. 线程安全和非线程安全区别

线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。

线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据

比如ArrayList是非线程安全的，Vector是线程安全的；HashMap是非线程安全的，HashTable是线程安全的；StringBuilder是非线程安全的，StringBuffer是线程安全的。

6. JMM 内存模型

Java 内存模型试图屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存
访问效果。

主内存与工作内存

处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。
加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主内存区域，那么多个缓存的数据可能会不一致，需要一些协议来解决这个问题。

解决缓存一致性方案有两种：

通过在总线加LOCK#锁的方式；
通过缓存一致性协议。

但是方案1存在一个问题，它是采用一种独占的方式来实现的，即总线加LOCK#锁的话，只能有一个CPU能够运行，其他CPU都得阻塞，效率较为低下。

方案二缓存一致性协议（MESI协议）它确保每个缓存中使用的共享变量的副本是一致的。所以JMM就解决这个问题。
在这里插入图片描述

JMM(Java内存模型Java Memory Model，简称JMM）本身是一种抽象的概念并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

JMM关于同步的规定：

线程解锁前，必须把共享变量的值刷新回主内存
线程加锁前，必须读取主内存的最新值到自己的工作内存
加锁解锁是同一把锁

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存（有些地方称为栈空间），工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法去访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成
在这里插入图片描述

内存间交互操作

Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作。
在这里插入图片描述

read：把一个变量的值从主内存传输到工作内存中
load：在 read 之后执行，把 read 得到的值放入工作内存的变量副本中
use：把工作内存中一个变量的值传递给执行引擎
assign：把一个从执行引擎接收到的值赋给工作内存的变量
store：把工作内存的一个变量的值传送到主内存中
write：在 store 之后执行，把 store 得到的值放入主内存的变量中
lock：作用于主内存的变量
unlock

内存模型三大特性

1. 原子性
Java 内存模型保证了 read、load、use、assign、store、write、lock 和 unlock 操作具有原子性，例如对一个 int 类型的变量执行 assign 赋值操作，这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的64 位数据（long，double）的读写操作划分为两次 32 位的操作来进行，即 load、store、read 和 write 操作可以不具备原子性。

有一个错误认识就是，int 等原子性的类型在多线程环境中不会出现线程安全问题。前面的线程不安全示例代码中，
cnt 属于 int 类型变量，1000 个线程对它进行自增操作之后，得到的值为 997 而不是 1000。

为了方便讨论，将内存间的交互操作简化为 3 个：load、assign、store。

下图演示了两个线程同时对 cnt 进行操作，load、assign、store 这一系列操作整体上看不具备原子性，那么在 T1修改 cnt 并且还没有将修改后的值写入主内存，T2 依然可以读入旧值。可以看出，这两个线程虽然执行了两次自增运算，但是主内存中 cnt 的值最后为 1 而不是 2。因此对 int 类型读写操作满足原子性只是说明 load、assign、store 这些单个操作具备原子性。
在这里插入图片描述
AtomicInteger 能保证多个线程修改的原子性。

除了使用原子类之外，也可以使用 synchronized 互斥锁来保证操作的原子性。它对应的内存间交互操作为：lock 和
unlock，在虚拟机实现上对应的字节码指令为 monitorenter 和 monitorexit。

2. 可见性
可见性指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值来实现可见性的。

主要有三种实现可见性的方式：

volatile
synchronized，对一个变量执行 unlock 操作之前，必须把变量值同步回主内存。
final，被 final 关键字修饰的字段在构造器中一旦初始化完成，并且没有发生 this 逃逸（其它线程通过 this 引用访问到初始化了一半的对象），那么其它线程就能看见 final 字段的值。

对前面的线程不安全示例中的 cnt 变量使用 volatile 修饰，不能解决线程不安全问题，因为 volatile 并不能保证操作的原子性

3. 有序性
有序性是指：在本线程内观察，所有操作都是有序的。在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序。在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。

volatile 关键字通过添加内存屏障的方式来禁止指令重排，即重排序时不能把后面的指令放到内存屏障之前。
也可以通过 synchronized 来保证有序性，它保证每个时刻只有一个线程执行同步代码，相当于是让线程顺序执行同步代码。

扩展：内存屏障(Memory Barrier)又称内存栅栏，是一个CPU指令，它的作用有两个：

保证特定操作的执行顺序，
保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）。

由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能
和这条MemoryBarrier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。内存屏障另外一个作
用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。

7. volatile解析

volatile是 java虚拟机提供的轻量级的同步机制（可以理解成乞丐版的synchronized）

特性有：

保证可见性
不保证原子性
禁止指令重排

1. 保证可见性
理解volatile特性之一保证可见性之前要先理解什么是JMM内存模型的可见性（参考上面），JMM 内存模型就是 volatile保证可见性特性的原理。

2. 不保证原子性
i++;这条代码可以分为3个步骤:

从主内存取值;
执行+1;
值重新写回主内存

如果使用volatile修饰,它只能保证第一步是从主内存取得最新值和指令不被重新排序.

例如:从主内存取到最新的值a=1，线程A执行完+1操作(a=2),如果这个时候线程A让出时间片,其他线程修改a的值为5,线程A继续执行，把a=2写如到主内存，这个时候就线程不安全了。主要原因就是把值写回到主内存时,并没有判断主内存的最新值和之前取到的值一样就写回主内存了。所以，volatile不保证原子性。

那么如何解决volatile不保证原子性的问题？
我们可以用java.util.concurrent.atomic包下的 AtomicInteger解决这个问题。

3. 禁止指令重排
volatile实现禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象。volatile禁止指令重排功能依赖内存屏障（内容见上）实现。

4. 单例模式下 volatile 的作用
在多线程环境下，底层为了优化有指令重排，加入volatile可以禁止指令重排。

private volatile static Singleton uniqueInstance;

    private Singleton() {

    }

    public static Singleton getUniqueInstance() {
        if (uniqueInstance == null) {
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }

8. 公平锁和非公平锁区别？为什么公平锁效率低？

1. 公平锁和非公平锁区别？

公平锁：在并发坏境中．每个线程在获取锁时会先查看此锁维护的等待队列，如果为空，或者当前线程是等待队列的第一个，就占有锁。否则就会加入到等待队列中，以后会按照FIFO的规则从队列中取到锁。
非公平锁：上来就直接尝试占有锁，如果尝试失败，就执行公平锁逻辑。

2. 为什么公平锁效率低？
公平锁要维护一个队列，后来的线程要加锁，即使锁空闲，也要先检查有没有其他线程在等待，如果有自己要挂起，加到队列后面，然后唤醒队列最前面的线程。这种情况下相比较非公平锁多了一次挂起和唤醒，多了线程切换的开销，这就是非公平锁效率高于公平锁的原因，因为非公平锁减少了线程挂起的几率，后来的线程有一定几率逃离被挂起的开销。

9. 锁优化（自旋锁、自适应自旋锁、锁消除、锁粗化、偏向锁、轻量级锁、重量级锁解释）

这里的锁优化主要是指 JVM 对 synchronized 的优化。

1. 自旋锁和自适应自旋锁
互斥同步对性能的最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成。在许多应用中，共享数据的锁定状态只会持续很短的一段时间。自旋锁的思想是让一个线程在请求一个共享数据的锁时执行忙循环（自旋）一段时间，如果在这段时间内能获得锁，就可以避免进入阻塞状态。

自旋锁虽然能避免进入阻塞状态从而减少开销，但是它需要进行忙循环操作占用 CPU 时间，它只适用于共享数据的锁定状态很短的场景。自旋等待的时间必须有一定的限度，超过了限定的次数仍然没有成功获取锁，就应当使用传统的方式挂起线程了。自旋次数的默认值是10，用户可以通过-XX:PreBlockSpin来更改。

在 JDK 1.6 中引入了自适应的自旋锁。自适应意味着自旋的次数不再固定了，而是由前一次在同一个锁上的自旋次数及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋线程之前刚刚获得过锁，且现在持有锁的线程正在运行中，那么虚拟机会认为这次自旋也很有可能会成功，进而允许该线程等待持续相对更长的时间，比如100个循环。反之，如果某个锁自旋很少获得过成功，那么之后再获取锁的时候将可能省略掉自旋过程，以避免浪费处理器资源。

2. 锁消除
锁消除是指对于被检测出不可能存在竞争的共享数据的锁进行消除。

锁消除主要是通过逃逸分析来支持，如果堆上的共享数据不可能逃逸出去被其它线程访问到，那么就可以把它们当成私有数据对待，也就可以将它们的锁进行消除。

对于一些看起来没有加锁的代码，其实隐式的加了很多锁。例如下面的字符串拼接代码就隐式加了锁：

public static String concatString(String s1, String s2, String s3) {
	return s1 + s2 + s3;
}

String 是一个不可变的类，编译器会对 String 的拼接自动优化。在 JDK 1.5 之前，会转化为StringBuffer 对象的连续 append() 操作：

public static String concatString(String s1, String s2, String s3) {
	StringBuffer sb = new StringBuffer();
	sb.append(s1);
	sb.append(s2);
	sb.append(s3);
	return sb.toString();
}

每个 append() 方法中都有一个同步块。虚拟机观察变量 sb，很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是说，sb 的所有引用永远不会逃逸到 concatString() 方法之外，其他线程无法访问到它，因此可以进行消除。

3. 锁粗化
如果一系列的连续操作都对同一个对象反复加锁和解锁，频繁的加锁操作就会导致性能损耗。

上一节的示例代码中连续的 append() 方法就属于这类情况。如果虚拟机探测到由这样的一串零碎的操作都对同一个对象加锁，将会把加锁的范围扩展（粗化）到整个操作序列的外部。对于上一节的示例代码就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，这样只需要加锁一次就可以了。

4. 偏向锁
引入偏向锁的目的和引入轻量级锁的目的很像，它们都是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。但是不同是：轻量级锁在无竞争的情况下使用 CAS 操作去代替使用互斥量，而偏向锁在无竞争的情况下会把整个同步都消除掉。

偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下，就会给线程加一个偏向锁。

如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。

5. 轻量级锁
轻量级锁的目标是，减少无实际竞争情况下，使用重量级锁产生的性能消耗，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。

如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥操作的开销。但如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因此在有锁竞争的情况下，轻量级锁比传统的重量级锁更慢，如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁。

6. 重量级锁
内置锁在Java中被抽象为监视器锁（monitor）。在JDK 1.6之前，监视器锁可以认为直接对应底层操作系统中的互斥量（mutex）。这种同步方式的成本非常高，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。因此称这种锁为“重量级锁”。

10. AQS原理及应用

1. AQS 介绍
AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。
在这里插入图片描述
AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。

2. AQS 原理概览
AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。

看个AQS(AbstractQueuedSynchronizer)原理图：
在这里插入图片描述
AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该
同步状态进行原子操作实现对其值的修改。

private volatile int state;//共享变量，使用volatile修饰保证线程可见性

状态信息通过procted类型的getState，setState，compareAndSetState进行操作。

//返回同步状态的当前值
protected final int getState() {
	return state;
}
// 设置同步状态的值
protected final void setState(int newState) {
	state = newState;
} 
//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
protected final boolean compareAndSetState(int expect, int update) {
	return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

3. AQS 对资源的共享方式
AQS定义两种资源共享方式

Exclusive（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁：
公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
Share（共享）：多个线程可同时执行，如Semaphore/CountDownLatch。Semaphore、

ReentrantReadWriteLock 可以看成是组合式，因为ReentrantReadWriteLock也就是读写锁允许多个线程同时对某
一资源进行读。

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方
式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。

4. AQS底层使用了模板方法模式
同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应
用）：

使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。

这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。

AQS使用了模板方法模式，自定义同步器时需要重写下面几个AQS提供的模板方法：

isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。

默认情况下，每个方法都抛出 UnsupportedOperationException 。这些方法的实现必须是内部线程安全的，并且
通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类
使用。

以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现 tryAcquire-tryRelease 、tryAcquireShared-tryReleaseShared 中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如 ReentrantReadWriteLock 。

5. AQS 组件总结
Semaphore(信号量)-允许多个线程同时访问： synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。

CountDownLatch （倒计时器）： CountDownLatch是一个同步工具类，用来协调多个线程之间的同步。这个工具通常用来控制线程等待，让一些线程阻塞直到另一些线程完成一系列操作后才被唤醒。

CyclicBarrier(循环栅栏)： CyclicBarrier的字面意思是可循环使用（Cyclic）的屏障（Barrier）。作用是让一组线程到达一个屏障（也可以叫
同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。CyclicBarrier默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用await方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

11. CAS

1. CAS是什么
CAS的全称为Compare-And-Swap，它是一条CPU并发原语。

它的功能是判断内存某个位置的值是否为期望值，如果是则更改为新的值，这个过程是原子的。

CAS并发原语体现在JAVA语言中就是sun.misc.Unsafe类中的CAS方法，JVM会帮我们实现CAS汇编指令。这是一种完全依赖于硬件的功能，通过它实现了原子操作。再次强调，由于CAS是一种系统原语，原语属于操作系统用语范畴范，是由若干条指令组成的，用于完成某个功能的一个过程，并且原语的执行必须是连续的，在执行过程中不允许被中断，也就说CAS是一条CPU的原了指令，不会造成所谓的数据不一致问题。

2. CAS底层原理Unsafe深入解析
Unsafe是CAS的核心类，由于Java方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe相当于一个后门，基于该类可以直接操作特定内存的数据。Unsafe类存在于sun.misc包中，其内部方法操作可以像C的指针一样直接操作内存，因为Java中CAS操作的执行依赖于Unsafe类的方法。

注意Unsafe类中的所有方法都是native修饰的，也就是Unsafe类中的方法都直接调用操作系统底层资源执行相应任务。
在这里插入图片描述
原子整型在i++中操作多线程环境下不需要加synchronized，也能保证线程安全，是因为它用的是Unsafe类，源代码如下：

getAndAddInt()方法底层调用的是unsafe，传三个参数，当前对象，内存地址偏移量，增量1。底层调用的是CAS思想，如果比较成功+1，失败再重新获得比较一次，直至成功为止。

var1 AtomicInteger 对象本身
var2 该对象值的引用地址
var4 需要变动的数量
var5 是用 var1，var2 找出的主内存中真实的值，用该对象当前的值与 var5 比较：如果相同，更新var5+var4并返回 var5。如果不同，继续取值然后再比较，直到更新完成。

3. CAS缺点

循环时间开销很大
通过看源码，我们发现有个do while，如果CAS失败，会一直进行尝试。如果CAS长时间一直不成功，可能会给CPU带来很大的开销。
只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作。但是，对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可用锁来保证原子性。ABA问题概述
CAS会导致"ABA问题”
CAS算法实现一个重要前提需要取出内存中某时刻的数据并在当下时刻比较并替换，那么在这个时间差类会导致数据的变化。
比如说一个线程1 从内存位置V中取出A，这时候另一个线程2 也从内存中取出A，并且线程2 了一些操作将值变成了B，然后线程2 又将V位置的数据变成A，这时候线程1 进行CAS作发现内存中仍然是A，然后线程One操作成功。
尽管线程One的CAS慢作成功，但是不代表这个过程就是没有问题的。
解决：解决ABA问题只靠CAS不能解决，还需要用到原子引用技术。即AtomicReference

12. 线程同步方法

1. 同步方法
synchronized 关键字修饰方法。由于 java 的每个对象都有一个内置锁，当用此关键字修饰方法时，内置锁会保护整个方法。在调用该方法前，需要获得内置锁，否则就处于阻塞状态。synchronized关键字也可以修饰静态方法，此时如果调用该静态方法，将会锁住整个类.

代码如下：

public synchronized void save(){}

2. 同步代码块
synchronized关键字修饰的语句块。被该关键字修饰的语句块会自动加上内置锁，从而实现同步。同步是一种高开销的操作，因此应该尽量减少同步内容。通常没有必要同步整个方法，使用synchronized代码块同步关键代码即可。

代码如下：

synchronized(object){}

3. 使用特殊域变量（volatile）实现线程同步

volatile关键字为域变量的访问提供一种免锁机制
使用volatile修饰域相当于告诉虚拟机该域可能被其他现象更新
因此每次使用该域就要重新计算，而不是使用寄存器中的值
volatile不会提供任何原子操作，它也不能用来修饰final类型的变量

4. 使用重入锁实现线程同步
在 javaSE5.0 新增了一个 java.concurrent 包来支持同步。ReentrantLock类可以重入、互斥、实现了Lock接口的锁。

5. 使用局部变量实现线程同步
如果使用ThreadLocal管理变量，则每一个使用变量的线程都获得该变量的副本，副本之间相互独立，这样每一个线程都可以随意修改自己的变量副本，而不会对其他线程产生影响。

ThreadLocal与同步机制：

ThreadLocal与同步机制都是为了解决多线程中相同变量的访问冲突问题
前者采用以“空间换时间”的方法，后者采用以“时间换空间”的方式

6.使用阻塞队列实现线程同步

7.使用原子变量实现线程同步
需要使用线程同步的根本原因在于对普通变量的操作不是原子的。

原子操作就是指将读取变量值、修改变量值、保存变量值看成一个整体来操作，即这几种行为要么同时完成，要么都不完成。

在java的util.concurrent.atomic包中提供了创建了原子类型变量的工具类，使用该类可以简化线程同步，其中AtomicInteger 表可以用原子方式更新int的值。

13. ThreadLocal

早在JDK 1.2的版本中就提供java.lang.ThreadLocal，ThreadLocal为解决多线程程序的并发问题提供了一种新的思路。

当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。

ThreadLocal是如何做到为每一个线程维护变量的副本的呢？在ThreadLocal类中有一个Map，用于存储每一个线程的变量副本，Map中元素的键为线程对象，而值对应线程的变量副本。

ThreadLocal 和同步机制的比较
ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。

在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。

而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。

14. ReenTrantLock原理

1. ReentrantLock基本概念

主要利用CAS+AQS队列来实现。
是可重入锁。可重入锁是指同一个线程可以多次获取同一把锁。ReentrantLock和synchronized都是可重入锁。
是可中断锁。可中断锁是指线程尝试获取锁的过程中，是否可以响应中断。synchronized是不可中断锁，而ReentrantLock则提供了中断功能。
支持公平锁与非公平锁。synchronized是非公平锁，而ReentrantLock的默认实现是非公平锁，但是也可以设置为公平锁。

与 synchronized 区别见上面 synchronized 笔记部分。

15. 线程状态，start,run,wait,notify,yiled,sleep,join等方法的作用以及区别

1. 线程状态

NEW：线程刚创建
RUNNABLE：在 JVM 中正在运行的线程
BLOCKED：线程处于阻塞状态，等待监视锁
WAITING：等待状态
TIMED_WAITING：等待指定的时间后重新被唤醒的状态
TERMINATED：执行完成

2. start,run,wait,notify,yiled,sleep,join作用及区别

1. run()和start()
把需要处理的代码放到run()方法中，start()方法启动线程将自动调用run()方法，这个由java的内存机制规定的。并且run()方法必需是public访问权限，返回值类型为void。

2. wait()
wait()方法使当前线程暂停执行并释放对象锁标示，让其他线程可以进入synchronized数据块，当前线程被放入对象等待池中。

3. notify() 和 notifyAll()

notifyAll()会唤醒所有的线程，notify()之后会唤醒一个线程。
notifyAll()调用后，会将所有线程由等待池移到锁池，然后参与锁的竞争，竞争成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争。而notify()只会唤醒一个线程，具体唤醒哪一个线程由虚拟机控制。

4. yiled()
使用 yield() 的目的是让具有相同优先级或者更高优先级的线程之间能够适当的轮换执行。当一个线程使用了yield( )方法之后，它就会把自己CPU执行的时间让掉，让自己或者其它的线程运行。

使当前线程从执行状态（运行状态）变为可执行态（就绪状态）。从而让其它具有相同优先级的等待线程获取执行权。但是，并不能保证在当前线程调用yield()之后，其它具有相同优先级的线程就一定能获得执行权。也有可能是当前线程又进入到“运行状态”继续运行。

5. sleep()

Thread类，必须带一个时间参数。
使调用该方法的线程进入停滞状态，所以执行 sleep() 的线程在指定的时间内肯定不会被执行。
sleep(long)是不会释放锁标志的，也就是说如果有synchronized同步块，其他线程仍然不能访问共享数据。
sleep(long)可使优先级低的线程得到执行的机会，当然也可以让同优先级的线程有执行的机会。
该方法要捕捉异常
用途：例如有两个线程同时执行(没有synchronized)一个线程优先级为MAX_PRIORITY，另一个为MIN_PRIORITY。如果没有Sleep()方法，只有高优先级的线程执行完毕后，低优先级的线程才能够执行；但是高优先级的线程sleep(500)后，低优先级就有机会执行了
总之，sleep()可以使低优先级的线程得到执行的机会，当然也可以让同优先级、高优先级的线程有执行的机会。

6. join()
join方法的主要作用就是同步，它可以使得线程之间的并行执行变为串行执行。在A线程中调用了B线程的 join() 方法时，表示只有当B线程执行完毕时，A线程才能继续执行。

7. wait()和notify(),notifyAll()是Object类的方法，sleep()和yield()是Thread类的方法。

8. 为什么wait和notify方法要在同步块中调用
wait()和notify()因为是线程之间的通信，它们存在竞态，会对对象的“锁标志”进行操作，所以它们必需在Synchronized函数或者 synchronized block 中进行调用。如果在non-synchronized 函数或 non-synchronized block 中进行调用，虽然能编译通过，但在运行时会发生IllegalMonitorStateException的异常。

9. wait和sleep区别

sleep()方法是Thread的静态方法，而wait是Object实例方法
wait()方法必须要在同步方法或者同步块中调用，也就是必须已经获得对象锁。而sleep()方法没有这个限制可以在任何地方种使用。另外，wait()方法会释放占有的对象锁，使得该线程进入等待池中，等待下一次获取资源。而sleep()方法只是会让出CPU并不会释放掉对象锁；
sleep()方法在休眠时间达到后如果再次获得CPU时间片就会继续执行，而wait()方法必须等待Object.notift/Object.notifyAll通知后，才会离开等待池，并且再次获得CPU时间片才会继续执行。
sleep方法有可能会抛出异常，所以需要进行异常处理；wait方法不需要处理。

16. 关于 Atomic 原子类

1. 介绍一下Atomic 原子类
Atomic 翻译成中文是原子的意思。 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不
会被其他线程干扰。所以，所谓原子类说简单点就是具有原子/原子操作特征的类。

并发包 java.util.concurrent 的原子类都存放在 java.util.concurrent.atomic 下,如下图所示。
在这里插入图片描述
2. AtomicInteger 类的原理
AtomicInteger 线程安全原理简单分析
AtomicInteger 类的部分源码：

// setup to use Unsafe.compareAndSwapInt for updates（更新操作时提供“比较并替换”的作用）
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;

static {
	try {
		valueOffset = unsafe.objectFieldOffset
		(AtomicInteger.class.getDeclaredField("value"));
	} catch (Exception ex) { throw new Error(ex); }
} 

private volatile int value;

AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免synchronized 的高开销，执行效率大为提升。

CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个volatile变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。

17. 线程池相关

1. 为什么要用线程池？

线程池提供了一种限制和管理资源（包括执行一个任务）的方式。每个线程池还维护一些基本统计信息，例如已完成任务的数量。

使用线程池的好处：

降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
提高响应速度。当任务到达时，任务可以不需要的等到线程创建就能立即执行。
提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

2. 执行execute()方法和submit()方法的区别是什么呢？

execute() 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；
submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。

3. 如何创建线程池

《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。

Executors 返回线程池对象的弊端如下：

FixedThreadPool 和 SingleThreadExecutor ：允许请求的队列长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致OOM。
CachedThreadPool 和 ScheduledThreadPool ：允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。

方式一：通过构造方法实现
在这里插入图片描述
方式二：通过Executor 框架的工具类Executors来实现，我们可以创建三种类型的ThreadPoolExecutor：

FixedThreadPool ：该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
SingleThreadExecutor：方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
CachedThreadPool：该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。

对应Executors工具类中的方法如图所示：
在这里插入图片描述

4. 线程池构造函数7大参数

在这里插入图片描述

corePoolSize:线程池中的常驻核心线程数
在创建了线程池后，当有请求任务来之后，就会安排池中的线程去执行请求任务，近似理解为今日当值线程。当线程池中的线程数目达到corePoolSize后，就会把到达的任务放到缓存队列当中。
maximumPoolSize：线程池能够容纳同时执行的最大线程数，此值必须大于等于1
keepAliveTime：多余的空闲线程的存活时间
当空闲时间达到keepAIiveTime值时，多余空闲线程会被销毁直到只剩下corePoolSize个线程为止
unit:keepAIiveTime的单位
workQueue：任务队列，被提交但尚未被执行的任务。
threadFactory: 表示生成线程池中工作线程的线程工厂，用于创建线程一般用默认的即可。
handIer：拒绝策略，表示当队列满了并且工作线程大于等于线程池的最大线程数 (maximumPoolSize) 处理方式

5. 线程池处理任务过程

在创建了线程池后，等待提交过来的任务请求。
当调用execute()方法添加一个请求任务时，线程池会做如下判断：
2.1 如果正在运行的线程数量小于corePoolSi，那么马上创建线程运行这个任务：
2.2 如果正在运行的线程数量大于或等于corePoolSize，那么将这个任务放入队列；
2.3 如果这时候队列满了且正在运行的线程数量还小maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务：
2.4 如果队列满了且正在运行的线程数量大于或等于maximumPoolSize，那么线程池会启动饱和拒绝策略来执行。
当一个线程完成在务时，它会从队列中取下一个任务来执行。
当一个线程无事可做超过一定的时间(keepAliveTime）时，线程池会判断：
如果当前运行的线程数大于corePoolSize，那么这个线程就被停掉。所以线程池的所有任务完成后它最终会收縮到corePoolSize的大小。

6. 线程池的4种拒绝策略理论概述

拒绝策略概述：等待队列已经满了，再也塞不下新任务了，同时，线程池中的max线程也达到了，无法继续为新任务服务。这时候我们就需要拒绝策略机制合理处理这个问题。

4种JDK内置拒绝策略

AbortPolicy(默认）：直接抛出RejectedExecutionException异常阻止系统正常运行。
CallerRunsPolicy："调用者运行"一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量。
DiscardOldestPolicy：抛弃队列中等待最久的任务，然后把当前任务加入队列中尝试再次提交当前任务。
DiscardPolicy：直接丢弃任务，不予任何处理也不抛出异常。如果允许任务丢失，这是最好的一种方案。

以上内置拒绝策略均实现了RejectedExecutionHandler接口

7. 线程池配置合理线程数

1. 要合理配置线程数首先要知道公司服务器或阿里云是几核的
代码查看服务器核数：

System.out.println(Runtime.getRuntime().availableProcessors());

比如我的CPU核数4核，执行结果：
在这里插入图片描述
2. 看是CPU密集型还是 IO密集型任务线程

1. CPU密集型

CPU密集的意思是该任务需要大量的运算，而没有阻塞，CPU一直全速运行。
CPU密集任务只有在真正的多核CPU上才可能得到加速（通过多线程），而在单核CPU上，无论你开几个模拟的多线程该任务都不可能得到加速，因为CPU总的运算能力就那些。
CPU密集型任务配置尽可能少的线程数量：
公式：CPU核数+1个线程的线程池

2. IO密集型
方法一：
由于IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程，如 CPU核数*2

方法二：

IO密集型，即该任务需要大量的IO，即大量的阻塞。
在单线程上运IO密集型的任务会导致浪费大量的CPU运算能力浪费在等待。所以在IO密集型任务中使用多线程可以大大的加速程序运行，即使在单核CPU上，这种加速主要就是利用了被浪费掉的阻塞时间。
IO密集型时，大部分线程都阻塞，故需要多配置线程数：
参考公式：CPU核数/（1-阻系数） 比如8核CPU：8/(1-0.9)=80个线程数，阻塞系数在0.8~0.9之间

18. 手写简单的线程池，体现线程复用

19. 手写消费者生产者模式

20. 手写阻塞队列

21. 手写多线程交替打印ABC

Lumos`

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
面经——多线程

面经——多线程JMM 内存模型volatile解析15. JMM 内存模型Java 内存模型试图屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。主内存与工作内存处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主...
复制链接

扫一扫