1.为什么需要多线程
- CPU增加了缓存，以均衡与内存的速度差异；//导致可见性问题
- 操作系统增加了进程、线程，以分时复用CPU，进而均衡CPU与I/O设备的速度差异；//导致原子性问题
- 编译程序优化指令执行次序，使得缓存能够得到更加合理的利用。//导致有序性问题
2.并发三要素
- 可见性-----〉 CPU缓存引起-----〉一个线程对共享变量的修改，另外一个线程能够立刻看到。
- 原子性-----〉分时复用引起-----〉一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打算，要么都不执行。
- 有序性-----〉重排序引起----〉程序执行的顺序按照代码的先后顺序执行。
详解重排序 重排序分三种类型：
- 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
- 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
- 内存系统的重排序。由于处理器使用缓存和读 / 写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：
上述的 1 属于编译器重排序，2 和 3 属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。
3.happens-before
- 程序顺序规则：一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
- 监视器锁规则：对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。
- volatile 变量规则：对一个 volatile 域的写，happens- before 于任意后续对这个 volatile 域的读。
- 传递性：如果 A happens- before B，且 B happens- before C，那么 A happens- before C。
4.synchronized
4.1 说一说自己对于 synchronized 关键字的了解
synchronized 关键字解决的是多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。 另外，在 Java 早期版本中，synchronized 属于 重量级锁，效率低下。 为什么呢？ 因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。 庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对 synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。 所以，你会发现目前的话，不论是各种开源框架还是 JDK 源码都大量使用了 synchronized 关键字。
4.2 说说自己是怎么使用 synchronized 关键字
synchronized 关键字最主要的三种使用方式：
- 修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁
synchronized void method() {
//业务代码
}
2.修饰静态方法: 也就是给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 class 的锁。因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管 new 了多少个对象，只有一份）。所以，如果一个线程 A 调用一个实例对象的非静态 synchronized 方法，而线程 B 需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
synchronized static void method() {
//业务代码
}- 修饰代码块 ：指定加锁对象，对给定对象/类加锁。synchronized(this|object) 表示进入同步代码库前要获得给定对象的锁。synchronized(类.class) 表示进入同步代码前要获得 当前 class 的锁。
synchronized(this) {
//业务代码
}
总结：
- synchronized 关键字加到 static 静态方法和 synchronized(class) 代码块上都是是给 Class 类上锁。
- synchronized 关键字加到实例方法上是给对象实例上锁。
- 尽量不要使用 synchronized(String a) 因为 JVM 中，字符串常量池具有缓存功能！
下面我以一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。 面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！” 双重校验锁实现对象单例（线程安全）
public class Singleton {
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;
}
}另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。 uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：
- 为 uniqueInstance 分配内存空间
- 初始化 uniqueInstance
- 将 uniqueInstance 指向分配的内存地址
但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。 使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。
4.3 构造方法可以使用 synchronized 关键字修饰么？
先说结论：构造方法不能使用 synchronized 关键字修饰。 构造方法本身就属于线程安全的，不存在同步的构造方法一说。
4.4 讲一下 synchronized 关键字的底层原理
synchronized 关键字底层原理属于 JVM 层面。
4.4.1 加锁和释放锁的原理
Monitorenter和Monitorexit指令，会让对象在执行，使其锁计数器加1或者减1。每一个对象在同一时间只与一个monitor(锁)相关联，而一个monitor在同一时间只能被一个线程获得，一个对象在尝试获得与这个对象相关联的Monitor锁的所有权的时候，monitorenter指令会发生如下3中情况之一：
- monitor计数器为0，意味着目前还没有被获得，那这个线程就会立刻获得然后把锁计数器+1，一旦+1，别的线程再想获取，就需要等待
- 如果这个monitor已经拿到了这个锁的所有权，又重入了这把锁，那锁计数器就会累加，变成2，并且随着重入的次数，会一直累加
- 这把锁已经被别的线程获取了，等待锁释放
monitorexit指令：释放对于monitor的所有权，释放过程很简单，就是讲monitor的计数器减1，如果减完以后，计数器不是0，则代表刚才是重入进来的，当前线程还继续持有这把锁的所有权，如果计数器变成0，则代表当前线程不再拥有该monitor的所有权，即释放锁。
下图表现了对象，对象监视器，同步队列以及执行线程状态之间的关系：
该图可以看出，任意线程对Object的访问，首先要获得Object的监视器，如果获取失败，该线程就进入同步状态，线程状态变为BLOCKED，当Object的监视器占有者释放后，在同步队列中得线程就会有机会重新获取该监视器。
4.4.2 可重入原理：加锁次数计数器
Synchronized先天具有重入性。每个对象拥有一个计数器，当线程获取该对象锁后，计数器就会加一，释放锁后就会将计数器减一。
4.4.3 保证可见性的原理：内存模型和happens-before规则
Synchronized的happens-before规则，即监视器锁规则：对同一个监视器的解锁，happens-before于对该监视器的加锁。
在图中每一个箭头连接的两个节点就代表之间的happens-before关系，黑色的是通过程序顺序规则推导出来，红色的为监视器锁规则推导而出：线程A释放锁happens-before线程B加锁，蓝色的则是通过程序顺序规则和监视器锁规则推测出来happens-befor关系，通过传递性规则进一步推导的happens-before关系。现在我们来重点关注2 happens-before 5，通过这个关系我们可以得出什么? 根据happens-before的定义中的一条:如果A happens-before B，则A的执行结果对B可见，并且A的执行顺序先于B。线程A先对共享变量A进行加一，由2 happens-before 5关系可知线程A的执行结果对线程B可见即线程B所读取到的a的值为1。
4.5 Synchronied中锁的优化
在Java SE 1.6里Synchronied同步锁，一共有四种状态：无锁、偏向锁、轻量级所、重量级锁，它会随着竞争情况逐渐升级。锁可以升级但是不可以降级，目的是为了提供获取锁和释放锁的效率。
锁膨胀方向： 无锁 → 偏向锁 → 轻量级锁 → 重量级锁 (此过程是不可逆的)
4.5.1 偏向锁
在大多实际环境下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获取，那么在同一个线程反复获取所释放锁中，其中并还没有锁的竞争，那么这样看上去，多次的获取锁和释放锁带来了很多不必要的性能开销和上下文切换。
为了解决这一问题，HotSpot的作者在Java SE 1.6 中对Synchronized进行了优化，引入了偏向锁。当一个线程访问同步快并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和推出同步块时不需要进行CAS操作来加锁和解锁。只需要简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果成功，表示线程已经获取到了锁。
- 偏向锁的撤销 偏向锁使用了一种等待竞争出现才会释放锁的机制。所以当其他线程尝试获取偏向锁时，持有偏向锁的线程才会释放锁。但是偏向锁的撤销需要等到全局安全点(就是当前线程没有正在执行的字节码)。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着。如果线程不处于活动状态，直接将对象头设置为无锁状态。如果线程活着，JVM会遍历栈帧中的锁记录，栈帧中的锁记录和对象头要么偏向于其他线程，要么恢复到无锁状态或者标记对象不适合作为偏向锁。
4.5.2 轻量级锁
在JDK 1.6之后引入的轻量级锁，需要注意的是轻量级锁并不是替代重量级锁的，而是对在大多数情况下同步块并不会有竞争出现提出的一种优化。它可以减少重量级锁对线程的阻塞带来地线程开销。从而提高并发性能。 如果要理解轻量级锁，那么必须先要了解HotSpot虚拟机中对象头地内存布局。上面介绍Java对象头也详细介绍过。在对象头中(Object Header)存在两部分。第一部分用于存储对象自身的运行时数据，HashCode、GC Age、锁标记位、是否为偏向锁。等。一般为32位或者64位(视操作系统位数定)。官方称之为Mark Word，它是实现轻量级锁和偏向锁的关键。 另外一部分存储的是指向方法区对象类型数据的指针(Klass Point)，如果对象是数组的话，还会有一个额外的部分用于存储数据的长度。
- 轻量级锁加锁 在线程执行同步块之前，JVM会先在当前线程的栈帧中创建一个名为锁记录(Lock Record)的空间，用于存储锁对象目前的Mark Word的拷贝(JVM会将对象头中的Mark Word拷贝到锁记录中，官方称为Displaced Mark Ward)这个时候线程堆栈与对象头的状态如图：
如上图所示：如果当前对象没有被锁定，那么锁标志位位01状态，JVM在执行当前线程时，首先会在当前线程栈帧中创建锁记录Lock Record的空间用于存储锁对象目前的Mark Word的拷贝。 然后，虚拟机使用CAS操作将标记字段Mark Word拷贝到锁记录中，并且将Mark Word更新为指向Lock Record的指针。如果更新成功了，那么这个线程就有用了该对象的锁，并且对象Mark Word的锁标志位更新为(Mark Word中最后的2bit)00，即表示此对象处于轻量级锁定状态，如图： 如果这个更新操作失败，JVM会检查当前的Mark Word中是否存在指向当前线程的栈帧的指针，如果有，说明该锁已经被获取，可以直接调用。如果没有，则说明该锁被其他线程抢占了，如果有两条以上的线程竞争同一个锁，那轻量级锁就不再有效，直接膨胀位重量级锁，没有获得锁的线程会被阻塞。此时，锁的标志位为10.Mark Word中存储的时指向重量级锁的指针。 轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头中，如果成功，则表示没有发生竞争关系。如果失败，表示当前锁存在竞争关系。锁就会膨胀成重量级锁。两个线程同时争夺锁，导致锁膨胀的流程图如下：
4.5.3 自旋锁、适应性自旋锁
自旋锁早在JDK1.4 中就引入了，只是当时默认时关闭的。在JDK 1.6后默认为开启状态。自旋锁本质上与阻塞并不相同，先不考虑其对多处理器的要求，如果锁占用的时间非常的短，那么自旋锁的性能会非常的好，相反，其会带来更多的性能开销(因为在线程自旋时，始终会占用CPU的时间片，如果锁占用的时间太长，那么自旋的线程会白白消耗掉CPU资源)。因此自旋等待的时间必须要有一定的限度，如果自选超过了限定的次数仍然没有成功获取到锁，就应该使用传统的方式去挂起线程了，在JDK定义中，自旋锁默认的自旋次数为10次，用户可以使用参数-XX:PreBlockSpin来更改。
在JDK 1.6中引入了自适应自旋锁。这就意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋 时间及锁的拥有者的状态来决定的。如果在同一个锁对象上，自旋等待刚刚成功获取过锁，并且持有锁的线程正在运行中，那么JVM会认为该锁自旋获取到锁的可能性很大，会自动增加等待时间。比如增加到100此循环。相反，如果对于某个锁，自旋很少成功获取锁。那再以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，JVM对程序的锁的状态预测会越来越准备，JVM也会越来越聪明。
4.5.4 重量级锁
在重量级锁中没有竞争到锁的对象会 park 被挂起，退出同步块时 unpark 唤醒后续线程。唤醒操作涉及到操作系统调度会有额外的开销。 参考xiaomi-info.github.io/2020/03/24/…
4.5.5 锁对比与总结
| 锁 | 优点 | 缺点 | 使用场景 |
|---|---|---|---|
| 偏向锁 | 加锁和解锁不需要CAS操作，没有额外的性能消耗，和执行非同步方法相比仅存在纳秒级的差距 | 如果线程间存在锁竞争，会带来额外的锁撤销的消耗 | 适用于只有一个线程访问同步快的场景 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了响应速度 | 如线程成始终得不到锁竞争的线程，使用自旋会消耗CPU性能 | 追求响应时间，同步快执行速度非常快 |
| 重量级锁 | 线程竞争不适用自旋，不会消耗CPU | 线程阻塞，响应时间缓慢，在多线程下，频繁的获取释放锁，会带来巨大的性能消耗 | 追求吞吐量，同步快执行速度较长 |
5.volatile详解
5.1 volatile的作用
- 防重排序
为了防止这个过程的重排序，我们需要将变量设置为volatile类型的变量。
- 实现可见性
可见性问题主要指一个线程修改了共享变量值，而另一个线程却看不到。引起可见性问题的主要原因是每个线程拥有自己的一个高速缓存区——线程工作内存。volatile关键字能有效的解决这个问题。
- 保证原子性:单次读/写
volatile不能保证完全的原子性，只能保证单次的读/写操作具有原子性。
5.2 volatile 的实现原理
5.2.1 volatile 可见性实现
volatile 变量的内存可见性是基于内存屏障(Memory Barrier)实现:
- 内存屏障，又称内存栅栏，是一个 CPU 指令。
- 在程序运行时，为了提高执行性能，编译器和处理器会对指令进行重排序，JMM 为了保证在不同的编译器和 CPU 上有相同的结果，通过插入特定类型的内存屏障来禁止+ 特定类型的编译器重排序和处理器重排序，插入一条内存屏障会告诉编译器和 CPU：不管什么指令都不能和这条 Memory Barrier 指令重排序。
5.2.2 volatile 有序性实现
5.2.2.1 volatile 的 happens-before 关系
happens-before 规则中有一条是 volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。
5.2.2.2 volatile 禁止重排序
为了性能优化，JMM 在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序。 JMM 提供了内存屏障阻止这种重排序。 Java 编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。 JMM 会针对编译器制定 volatile 重排序规则表。
" NO " 表示禁止重排序。 为了实现 volatile 内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。 对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM 采取了保守的策略。
- 在每个 volatile 写操作的前面插入一个 StoreStore 屏障。
- 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。
- 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
- 在每个 volatile 读操作的后面插入一个 LoadStore 屏障。 volatile 写是在前面和后面分别插入内存屏障，而 volatile 读操作是在后面插入两个内存屏障。
| 内存屏障 | 说明 |
|---|---|
| StoreStore 屏障 | 禁止上面的普通写和下面的 volatile 写重排序。 |
| StoreLoad 屏障 | 防止上面的 volatile 写与下面可能有的 volatile 读/写重排序。 |
| LoadLoad 屏障 | 禁止下面所有的普通读操作和上面的 volatile 读重排序。 |
| LoadStore 屏障 | 禁止下面所有的普通写操作和上面的 volatile 读重排序。 |
5.3 volatile 的应用场景
使用 volatile 必须具备的条件
- 对变量的写操作不依赖于当前值。
- 该变量没有包含在具有其他变量的不变式中。
- 只有在状态真正独立于程序内其他内容时才能使用 volatile。
5.3.1 状态标志
5.3.2 一次性安全发布(one-time safe publication)
5.3.3 独立观察(independent observation)
5.3.4 volatile bean 模式
5.3.5 开销较低的读－写锁策略
5.3.6 双重检查(double-checked)
6.final详解
6.1 final基础使用
- 修饰类
当某个类的整体定义为final时，就表明了你不能打算继承该类，而且也不允许别人这么做。即这个类是不能有子类的。
- 修饰方法
private 方法是隐式的final final方法是可以被重载的
- 修饰参数
Java允许在参数列表中以声明的方式将参数指明为final，这意味这你无法在方法中更改参数引用所指向的对象。这个特性主要用来向匿名内部类传递数据。
- 修饰变量
不是所有的final修饰的字段都是编译期常量 一个既是static又是final 的字段只占据一段不能改变的存储空间，它必须在定义的时候进行赋值，否则编译器将不予通过。 Java允许生成空白final，也就是说被声明为final但又没有给出定值的字段,但是必须在该字段被使用之前被赋值
6.2 final域重排序规则
6.2.1 写final域重排序规则【基本类型】
写final域的重排序规则禁止对final域的写重排序到构造函数之外，这个规则的实现主要包含了两个方面：
- JMM禁止编译器把final域的写重排序到构造函数之外；
- 编译器会在final域写之后，构造函数return之前，插入一个storestore屏障。这个屏障可以禁止处理器把final域的写重排序到构造函数之外。
写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域就不具有这个保障。
6.2.2 读final域重排序规则【基本类型】
读final域重排序规则为：在一个线程中，初次读对象引用和初次读该对象包含的final域，JMM会禁止这两个操作的重排序。(注意，这个规则仅仅是针对处理器)，处理器会在读final域操作的前面插入一个LoadLoad屏障。实际上，读对象的引用和读该对象的final域存在间接依赖性，一般处理器不会重排序这两个操作。但是有一些处理器会重排序，因此，这条禁止重排序规则就是针对这些处理器而设定的。
读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读这个包含这个final域的对象的引用。
6.2.3 对final修饰的对象的成员域写操作【引用类型】
针对引用数据类型，final域写针对编译器和处理器重排序增加了这样的约束：在构造函数内对一个final修饰的对象的成员域的写入，与随后在构造函数之外把这个被构造的对象的引用赋给一个引用变量，这两个操作是不能被重排序的。
6.2.4 对final修饰的对象的成员域读操作【引用类型】
6.2.5 关于final重排序的总结
按照final修饰的数据类型分类
-
基本数据类型:
- final域写：禁止final域写与构造方法重排序，即禁止final域写重排序到构造方法之外，从而保证该对象对所有线程可见时，该对象的final域全部已经初始化过。
- final域读：禁止初次读对象的引用与读该对象包含的final域的重排序。
-
引用数据类型：
- 额外增加约束：禁止在构造函数对一个final修饰的对象的成员域的写入与随后将这个被构造的对象的引用赋值给引用变量 重排序
6.3 final的实现原理
上面我们提到过，写final域会要求编译器在final域写之后，构造函数返回前插入一个StoreStore屏障。读final域的重排序规则会要求编译器在读final域的操作前插入一个LoadLoad屏障。 很有意思的是，如果以X86处理为例，X86不会对写-写重排序，所以StoreStore屏障可以省略。由于不会对有间接依赖性的操作重排序，所以在X86处理器中，读final域需要的LoadLoad屏障也会被省略掉。也就是说，以X86为例的话，对final域的读/写的内存屏障都会被省略！具体是否插入还是得看是什么处理器.
7.JUC相关
7.1 线程安全的实现方法有哪些?
- 互斥同步: synchronized 和 ReentrantLock
- 非阻塞同步: CAS, AtomicXXXX
- 无同步方案: 栈封闭，Thread Local，可重入代码
7.2 CAS
7.2.1 什么是CAS?
CAS的全称为Compare-And-Swap，直译就是对比交换。是一条CPU的原子指令，其作用是让CPU先进行比较两个值是否相等，然后原子地更新某个位置的值，经过调查发现，其实现方式是基于硬件平台的汇编指令，就是说CAS是靠硬件实现的，JVM只是封装了汇编调用，那些AtomicInteger类便是使用了这些封装后的接口。
7.2.2 CAS会有哪些问题?
- ABA问题
ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A->B->A就会变成1A->2B->3A。 从Java 1.5开始，JDK的Atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法的作用是首先检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
- 循环时间长开销大
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令，那么效率会有一定的提升。pause指令有两个作用：第一，它可以延迟流水线执行命令(de-pipeline)，使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零；第二，它可以避免在退出循环的时候因内存顺序冲突(Memory Order Violation)而引起CPU流水线被清空(CPU Pipeline Flush)，从而提高CPU的执行效率。
- 只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁。 还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i = 2，j = a，合并一下ij = 2a，然后用CAS来操作ij。 从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。
7.2.3 AtomicInteger底层实现?
AtomicInteger 底层用的是volatile的变量和CAS来进行更改数据的
- volatile保证线程的可见性，多线程并发时，一个线程修改数据，可以保证其它线程立马看到修改后的值
- CAS 保证数据更新的原子性。
7.2.4 AtomicStampedReference 是什么?是怎么解决ABA的?
AtomicStampedReference主要维护包含一个对象引用以及一个可以自动更新的整数"stamp"的pair对象来解决ABA问题。
7.2.5 java中还有哪些类可以解决ABA的问题?
AtomicMarkableReference，它不是维护一个版本号，而是维护一个boolean类型的标记，标记值有修改。
7.3 LockSupport
7.3.1 为什么LockSupport也是核心基础类?
AQS框架借助于两个类：Unsafe(提供CAS操作)和LockSupport(提供park/unpark操作)
7.3.2 LockSupport.park()会释放锁资源吗? 那么Condition.await()呢?
不会，它只负责阻塞当前线程，释放锁资源实际上是在Condition的await()方法中实现的。
7.3.3 Thread.sleep()和Object.wait()的区别？
- Thread.sleep()不会释放占有的锁，Object.wait()会释放占有的锁；
- Thread.sleep()必须传入时间，Object.wait()可传可不传，不传表示一直阻塞下去；
- Thread.sleep()到时间了会自动唤醒，然后继续执行；
- Object.wait()不带时间的，需要另一个线程使用Object.notify()唤醒； Object.wait()带时间的，假如没有被notify，到时间了会自动唤醒，这时又分好两种情况，一是立即获取到了锁，线程自然会继续执行；二是没有立即获取锁，线程进入同步队列等待获取锁；
其实，他们俩最大的区别就是Thread.sleep()不会释放锁资源，Object.wait()会释放锁资源。
7.3.4 Object.wait()和Condition.await()的区别？
Object.wait()和Condition.await()的原理是基本一致的，不同的是Condition.await()底层是调用LockSupport.park()来实现阻塞当前线程的。 实际上，它在阻塞当前线程之前还干了两件事，一是把当前线程添加到条件队列中，二是“完全”释放锁，也就是让state状态变量变为0，然后才是调用LockSupport.park()阻塞当前线程。
7.3.5 Thread.sleep()和LockSupport.park()的区别？
- 从功能上来说，Thread.sleep()和LockSupport.park()方法类似，都是阻塞当前线程的执行，且都不会释放当前线程占有的锁资源； - Thread.sleep()没法从外部唤醒，只能自己醒过来；
- LockSupport.park()方法可以被另一个线程调用LockSupport.unpark()方法唤醒；
- Thread.sleep()方法声明上抛出了InterruptedException中断异常，所以调用者需要捕获这个异常或者再抛出；
- LockSupport.park()方法不需要捕获中断异常；
- Thread.sleep()本身就是一个native方法；
- LockSupport.park()底层是调用的Unsafe的native方法；
7.3.6 Object.wait()和LockSupport.park()的区别？
- Object.wait()方法需要在synchronized块中执行；
- LockSupport.park()可以在任意地方执行；
- Object.wait()方法声明抛出了中断异常，调用者需要捕获或者再抛出；
- LockSupport.park()不需要捕获中断异常；
- Object.wait()不带超时的，需要另一个线程执行notify()来唤醒，但不一定继续执行后续内容；
- LockSupport.park()不带超时的，需要另一个线程执行unpark()来唤醒，一定会继续执行后续内容；
- 如果在wait()之前执行了notify()会怎样? 抛出IllegalMonitorStateException异常；
- 如果在park()之前执行了unpark()会怎样? 线程不会被阻塞，直接跳过park()，继续执行后续内容；
park()/unpark()底层的原理是“二元信号量”，你可以把它相像成只有一个许可证的Semaphore，只不过这个信号量在重复执行unpark()的时候也不会再增加许可证，最多只有一个许可证。
7.4 AQS
7.4.1 什么是AQS? 为什么它是核心?
AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。
7.4.2 AQS的核心思想是什么? 它是怎么实现的? 底层数据结构等？
AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。
CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系)。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点(Node)来实现锁的分配。
AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该同步状态进行原子操作实现对其值的修改。
AbstractQueuedSynchronizer数据结构
AbstractQueuedSynchronizer类底层的数据结构是使用CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系)。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点(Node)来实现锁的分配。其中Sync queue，即同步队列，是双向链表，包括head结点和tail结点，head结点主要用作后续的调度。而Condition queue不是必须的，其是一个单向链表，只有当使用Condition时，才会存在此单向链表。并且可能会有多个Condition queue。
7.4.3 AQS有哪些核心的方法?
acquire方法
该方法以独占模式获取(资源)，忽略中断，即线程在aquire过程中，中断此线程是无效的。
release方法
以独占模式释放对象
7.4.4 AQS定义什么样的资源获取方式?
AQS定义了两种资源获取方式： 独占(只有一个线程能访问执行，又根据是否按队列的顺序分为公平锁和非公平锁，如ReentrantLock) 和共享(多个线程可同时访问执行，如Semaphore、CountDownLatch、 CyclicBarrier )。ReentrantReadWriteLock可以看成是组合式，允许多个线程同时对某一资源进行读。
7.4.5 AQS底层使用了什么样的设计模式?
同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样.
7.4.6 AbstractQueuedSynchronizer总结
对于AbstractQueuedSynchronizer的分析，最核心的就是sync queue的分析。
- 每一个结点都是由前一个结点唤醒
- 当结点发现前驱结点是head并且尝试获取成功，则会轮到该线程运行。
- condition queue中的结点向sync queue中转移是通过signal操作完成的。
- 当结点的状态为SIGNAL时，表示后面的结点需要运行。
7.5 ReentrantLock
7.5.1 什么是可重入，什么是可重入锁? 它用来解决什么问题?
可重入锁，也叫做递归锁，是指在一个线程中可以多次获取同一把锁。 最大的作用是避免死锁。 在很多情况下线程需要多次进入锁内执行任务。
7.5.2 ReentrantLock 常用的方法有哪些？
- lock()：用于获取锁
- unlock()：用于释放锁
- tryLock()：尝试获取锁
- getHoldCount()：查询当前线程执行 lock() 方法的次数
- getQueueLength()：返回正在排队等待获取此锁的线程数
- isFair()：该锁是否为公平锁
7.5.3 ReentrantLock 有哪些优势?
ReentrantLock 具备非阻塞方式获取锁的特性，使用 tryLock() 方法。ReentrantLock 可以中断获得的锁，使用 lockInterruptibly() 方法当获取锁之后，如果所在的线程被中断，则会抛出异常并释放当前获得的锁。ReentrantLock 可以在指定时间范围内获取锁，使用 tryLock(long timeout,TimeUnit unit) 方法。
7.5.4 synchronized 和 ReentrantLock 有什么区别？
synchronized 和 ReentrantLock 都是保证线程安全的，它们的区别如下：
- ReentrantLock 使用起来比较灵活，但是必须有释放锁的配合动作；
- ReentrantLock 必须手动获取与释放锁，而 synchronized 不需要手动释放和开启锁；
- ReentrantLock 只适用于代码块锁，而 synchronized 可用于修饰方法、代码块等；
- ReentrantLock 性能略高于 synchronized。
7.5.5 ReentrantLock默认实现的是公平还是非公平锁?
默认实现的是非公平锁，创建如下： new ReentrantLock(); 创建公平锁为 new ReentrantLock(true);
7.6 ConcurrentHashMap
7.6.1 为什么HashTable慢?
Hashtable之所以效率低下主要是因为其实现使用了synchronized关键字对put等操作进行加锁，而synchronized关键字加锁是对整个对象进行加锁，也就是说在进行put等修改Hash表的操作时，锁住了整个Hash表，从而使得其表现的效率低下。
7.6.2 实现原理
- jdk1.7 在JDK1.7中ConcurrentHashMap采用了数组+Segment+分段锁的方式实现。
-
Segment(分段锁) ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表,同时又是一个ReentrantLock（Segment继承了ReentrantLock）。
-
内部结构 ConcurrentHashMap使用分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。如下图是ConcurrentHashMap的内部结构图：
从上面的结构我们可以了解到，ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作。 第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部。
- 该结构的优劣势 坏处: 这一种结构的带来的副作用是Hash的过程要比普通的HashMap要长 好处: 写操作的时候可以只对元素所在的Segment进行加锁即可，不会影响到其他的Segment，这样，在最理想的情况下，ConcurrentHashMap可以最高同时支持Segment数量大小的写操作（刚好这些写操作都非常平均地分布在所有的Segment上）。 所以，通过这一种结构，ConcurrentHashMap的并发能力可以大大的提高。
-
jdk1.8 JDK8中ConcurrentHashMap参考了JDK8 HashMap的实现，采用了数组+链表+红黑树的实现方式来设计，内部大量采用CAS操作，这里我简要介绍下CAS。 CAS是compare and swap的缩写，即我们所说的比较交换。cas是一种基于锁的操作，而且是乐观锁。在java中锁分为乐观锁和悲观锁。悲观锁是将资源锁住，等一个之前获得锁的线程释放锁之后，下一个线程才可以访问。而乐观锁采取了一种宽泛的态度，通过某种方式不加锁来处理资源，比如通过给记录加version来获取数据，性能较悲观锁有很大的提高。 CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。如果内存地址里面的值和A的值是一样的，那么就将内存里面的值更新成B。CAS是通过无限循环来获取数据的，若果在第一轮循环中，a线程获取地址里面的值被b线程修改了，那么a线程需要自旋，到下次循环才有可能机会执行。 JDK8中彻底放弃了Segment转而采用的是Node，其设计思想也不再是JDK1.7中的分段锁思想。 Node：保存key，value及key的hash值的数据结构。其中value和next都用volatile修饰，保证并发的可见性。 Java8 ConcurrentHashMap结构基本上和Java8的HashMap一样，不过保证线程安全性。 在JDK8中ConcurrentHashMap的结构，由于引入了红黑树，使得ConcurrentHashMap的实现非常复杂，我们都知道，红黑树是一种性能非常好的二叉查找树，其查找性能为O（logN），但是其实现过程也非常复杂，而且可读性也非常差，DougLea的思维能力确实不是一般人能比的，早期完全采用链表结构时Map的查找时间复杂度为O（N），JDK8中ConcurrentHashMap在链表的长度大于某个阈值的时候会将链表转换成红黑树进一步提高其查找性能。 总结 其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树。
-
数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。
-
保证线程安全机制：JDK1.7采用segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8采用CAS+Synchronized保证线程安全。
-
锁的粒度：原来是对需要进行数据操作的Segment加锁，现调整为对每个数组元素加锁（Node）。
-
链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加剧,因此在链表节点数量大于8时，会将链表转化为红黑树进行存储。
-
查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。
7.7 CopyOnWriteArrayList
7.7.1 Fail-fast机制?
在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改(增加、删除、修改)，则会抛出Concurrent Modification Exception。
原理：迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化，就会改变modCount的值。每当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount变量是否为expectedmodCount值，是的话就返回遍历；否则抛出异常，终止遍历。
注意：这里异常的抛出条件是检测到 modCount！=expectedmodCount 这个条件。如果集合发生变化时修改modCount值刚好又设置为了expectedmodCount值，则异常不会抛出。因此，不能依赖于这个异常是否抛出而进行并发操作的编程，这个异常只建议用于检测并发修改的bug。 场景：java.util包下的集合类都是快速失败的，不能在多线程下发生并发修改(迭代过程中被修改)。
7.7.2 实现原理
CopyOnWriteArrayList容器允许并发读，读操作是无锁的，性能较高。至于写操作，比如向容器中添加一个元素，则首先将当前容器复制一份，然后在新副本上执行写操作，结束之后再将原容器的引用指向新容器。
7.7.3 优缺点
优点： 读操作性能很高，因为无需任何同步措施，比较适用于读多写少的并发场景。Java的list在遍历时，若中途有别的线程对list容器进行修改，则会抛出ConcurrentModificationException异常。而CopyOnWriteArrayList由于其"读写分离"的思想，遍历和修改操作分别作用在不同的list容器，所以在使用迭代器进行遍历时候，也就不会抛出ConcurrentModificationException异常了
缺点： 缺点也很明显，一是内存占用问题，毕竟每次执行写操作都要将原容器拷贝一份，数据量大时，对内存压力较大，可能会引起频繁GC；二是无法保证实时性，Vector对于读写操作均加锁同步，可以保证读和写的强一致性。而CopyOnWriteArrayList由于其实现策略的原因，写和读分别作用在新老不同容器上，在写操作执行过程中，读不会阻塞但读取到的却是老容器的数据。
7.7.4 CopyOnWriteArrayList为什么并发安全且性能比Vector好?
Vector对单独的add，remove等方法都是在方法上加了synchronized; 并且如果一个线程A调用size时，另一个线程B 执行了remove，然后size的值就不是最新的，然后线程A调用remove就会越界(这时就需要再加一个Synchronized)。这样就导致有了双重锁，效率大大降低，何必呢。于是vector废弃了，要用就用CopyOnWriteArrayList 吧。
7.8 ConcurrentLinkedQueue
7.8.1 ConcurrentLinkedQueue数据结构
通过源码分析可知，ConcurrentLinkedQueue的数据结构与LinkedBlockingQueue的数据结构相同，都是使用的链表结构。ConcurrentLinkedQueue的数据结构如下:
说明: ConcurrentLinkedQueue采用的链表结构，并且包含有一个头结点和一个尾结点。
7.8.2 谈下对基于链表的非阻塞无界队列 ConcurrentLinkedQueue 原理的理解？
7.8.3 ConcurrentLinkedQueue 内部是如何使用 CAS 非阻塞算法来保证多线程下入队出队操作的线程安全？
7.9 CountDownLatch
7.9.1 什么是CountDownLatch？
从源码可知，其底层是由AQS提供支持，所以其数据结构可以参考AQS的数据结构，而AQS的数据结构核心就是两个虚拟队列: 同步队列sync queue 和条件队列condition queue，不同的条件会有不同的条件队列。CountDownLatch典型的用法是将一个程序分为n个互相独立的可解决任务，并创建值为n的CountDownLatch。当每一个任务完成时，都会在这个锁存器上调用countDown，等待问题被解决的任务调用这个锁存器的await，将他们自己拦住，直至锁存器计数结束。
countdownlatch 能够让一个线程等待其他线程工作完成之后再执行。
countdownlatch 通过一个计数器来实现，初始值是指定的数量，每当一个线程完成自己的任务后，计数器减一，当计数器为 0 时，执行最后的等待线程。
7.9.2 CountDownLatch原理
其实CountDownLatch用的底层原理就是AQS， 可以参考：(AQS原理详解)。AQS全局维护的有一个volatile修饰的state字段，当state为0时就会通知countDownLatch等待线程执行。 await()方法, 其底层调用的就是AQS中的getState方法，通过判断state是否为0来决定是否唤醒等待的线程。 如果不为0则调用Unsafe中的park方法进行自旋，直到state==0时才继续往下执行（唤醒等待的线程）。 看到上面await方法了，那么countDown就可以直接猜出来了，无外乎就是使得AQS中的state通过CAS操作进行减一，如下：
7.10 CyclicBarrier
CyclicBarrier是回环栅栏的概念，多线程来的进行阻塞，等待某一个临界值条件满足后，同时执行。
7.10.2 CyclicBarrier原理
CyclicBarrier是通过ReentrantLock和Condition来实现的。
7.10.2 CountdownLatch和CyclicBarrier的区别
- CountDownLatch简单的说就是一个线程等待，直到他所等待的其他线程都执行完成并且调用countDown()方法发出通知后，当前线程才可以继续执行。
- CyclicBarrier是所有线程都进行等待，直到所有线程都准备好进入await()方法之后，所有线程同时开始执行！
- CountDownLatch的计数器只能使用一次。而CyclicBarrier的计数器可以使用reset() 方法重置。所以CyclicBarrier能处理更为复杂的业务场景，比如如果计算发生错误，可以重置计数器，并让线程们重新执行一次。
CountDownLatch 的实现是基于 AQS 的，而 CycliBarrier 是基于 ReentrantLock(ReentrantLock 也属于 AQS 同步器)和 Condition 的。
CountDownLatch 是共享锁的一种实现,它默认构造 AQS 的 state 值为 count。当线程使用 countDown() 方法时,其实使用了tryReleaseShared方法以 CAS 的操作来减少 state,直至 state 为 0 。当调用 await() 方法的时候，如果 state 不为 0，那就证明任务还没有执行完毕，await() 方法就会一直阻塞，也就是说 await() 方法之后的语句不会被执行。然后，CountDownLatch 会自旋 CAS 判断 state == 0，如果 state == 0 的话，就会释放所有等待的线程，await() 方法之后的语句得到执行。
CyclicBarrier 默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用 await() 方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。
7.11 Semaphore
Semaphore 就是一个共享锁，通过设置 state 变量来实现对这个变量的共享。当调用 acquire 方法的时候，state 变量就减去一，当调用 release 方法的时候，state 变量就加一。当 state 变量为 0 的时候，别的线程就不能进入代码块了，就会在 AQS 中阻塞等待。
7.12 ThreadLocal
7.12.1 ThreadLocal实现原理
-
如何实现线程隔离 主要是用到了Thread对象中的一个ThreadLocalMap类型的变量threadLocals。
-
首先获取当前线程对象t, 然后从线程t中获取到ThreadLocalMap的成员属性threadLocals
-
如果当前线程的threadLocals已经初始化(即不为null) 并且存在以当前ThreadLocal对象为Key的值, 则直接返回当前线程要获取的对象(本例中为Connection);
-
如果当前线程的threadLocals已经初始化(即不为null)但是不存在以当前ThreadLocal对象为Key的的对象, 那么重新创建一个Connection对象, 并且添加到当前线程的threadLocals Map中,并返回
-
如果当前线程的threadLocals属性还没有被初始化, 则重新创建一个ThreadLocalMap对象, 并且创建一个Connection对象并添加到ThreadLocalMap对象中并返回。
ThreadLocal能够实现变量的多线程隔离其实就是用了Map的数据结构给当前线程缓存了。
7.12.2 ThreadLocal内存泄漏问题
实际上 ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用，弱引用的特点是，如果这个对象只存在弱引用，那么在下一次垃圾回收的时候必然会被清理掉。 所以如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会被清理掉的，这样一来 ThreadLocalMap中使用这个 ThreadLocal 的 key 也会被清理掉。但是，value 是强引用，不会被清理，这样一来就会出现 key 为 null 的 value。 ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。如果说会出现内存泄漏，那只有在出现了 key 为 null 的记录后，没有手动调用 remove() 方法，并且之后也不再调用 get()、set()、remove() 方法的情况下。 建议回收自定义的ThreadLocal变量，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的 ThreadLocal变量，可能会影响后续业务逻辑和造成内存泄露等问题。 尽量在代理中使用try-finally块进行回收：
objectThreadLocal.set(userInfo);
try {
// ...
}
finally {
objectThreadLocal.remove();
}
复制代码7.12.3 使用场景
- 线程间数据隔离，各线程的 ThreadLocal 互不影响
- 方便同一个线程使用某一对象，避免不必要的参数传递
- 全链路追踪中的 traceId 或者流程引擎中上下文的传递一般采用 ThreadLocal
- Spring 事务管理器采用了 ThreadLocal
- Spring MVC 的 RequestContextHolder 的实现使用了 ThreadLocal
8.常用线程池有几种，平时怎么使用线程池?
第1种，newSingleThreadExecutor，创建了一个单线程的线程池，此线程池保证了所有任务的执行顺序都是按照任务的提交顺序执行。也就是说，这个池子里只有一个线程。 第2种，newFixedThreadPool，创建指定数量线程的线程池； 第3种，newCachedThreadPool，创建一个可缓存的线程池，伸缩性、动态调整，60s回收一次； 第4种，newScheduledThreadPool，创建一个大小无限的线程池； 第5种，newSingleThreadScheduledExecutor()，创建一个单例线程池，定期或延时执行任务，很多框架中使用此实现定时心跳检测。 第6种，newWorkStealingPool，这是Java 8 新增创建线程池的方法。
线程池的实际业务场景：线程池适合单系统的大量的异步任务处理，比如发送短信、保存日志。
线程池的使用见cloud.tencent.com/developer/a…
9.线程池参数有几种，拒绝策略有几种
线程池一共有7个参数： maximumPoolSize，指的是最大线程数 corePoolSize，指的是核心线程数 keepAliveTime ，指的是最大线程活跃时间 unit: 指定了keepAliveTime的单位，可以为毫秒，秒，分，小时等； workQueue: 存储未执行的任务的队列； threadFactory: 创建线程的工厂，如果未指定则使用默认的线程工厂； handler: 指定了当任务队列已满，并且没有可用线程执行任务时对新添加的任务的处理策略；
线程池中主要有4种拒绝策略： AbortPolicy，这是默认策略，指的是丢弃任务，抛出异常； CallerRunsPolicy，简单的说，就是后面排队的线程就在那等着，被拒绝的任务在主线程中运行，所以主线程就被阻塞了，别的任务只能在被拒绝的任务执行完后，才会继续被提交到线程池中。 DiscardOldestPolicy，指的是丢弃等待队列中最久的任务，并且执行当前任务； DiscardPolicy，直接丢弃任务，也不抛异常。
10.一个任务加入线程池的流程，keepalived怎么实现的
1、线程池提交任务首先判断当前线程数是否大于核心线程数, 否则创建核心线程执行任务 2、如果当前线程超过了核心线程数, 判断阻塞队列是否已满, 否则将任务添加到队列中 3、如果阻塞队列已满, 判断当前线程是否大于最大线程数, 否则创建非核心线程执行任务 4、如果当前线程大于或等于最大线程数, 执行拒绝策略
keepalived怎么实现的 通过阻塞队列 workQueue 的 poll 方法，当超过 keepAliveTime 的时候后还无法获取新的任务，则返回 null， 最后在 runWorker 方法中结束线程整个生命
11.submit()和execute()方法的区别？
submit() 和 execute()方法都是用来提交任务的，指的是把我们创建的任务提交到线程池中。 两者的不同点在于，调用 execute() 方法提交任务不能拿到任务的返回值，而调用 submit() 可以使用 Future 接收线程池执行任务的返回值。 这里就可以联想到，我们创建线程的方式中，有的方式可以拿到线程返回值，有的拿不到。 另外，execute()方法是ThreadPoolExecutor的方法，而submit() 方法是ThreadPoolExecutor的父类AbstractExecutorService中的方法。
submit()和execute()的区别：
- 接收的参数不一样
- submit()方法有返回值Future，而execute()方法没有返回值
- submit()方法方便处理Exception异常，意思就是，你在task里会抛出checked或者unchecked exception， 而又希望外面的调用者能够感知这些exception并作出及时的处理，用 submit，通过捕获Future.get抛出的异常
12. 为什么不建议使用Executors创建线程，而使用ThreadPoolExecutor实现类来创建线程？（jishuin.proginn.com/p/763bfbd34…
阿里巴巴开发手册为什么禁止使用 Executors 去创建线程池，原因就是 newFixedThreadPool() 和 newSingleThreadExecutor()两个方法允许请求的最大队列长度是 Integer.MAX_VALUE ，可能会出现任务堆积，出现OOM。newCachedThreadPool()允许创建的线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，导致发生OOM。它建议使用ThreadPoolExecutor方式去创建线程池，通过上面的分析我们也知道了其实Executors 三种创建线程池的方式最终就是通过ThreadPoolExecutor来创建的，只不过有些参数我们无法控制，如果通过ThreadPoolExecutor的构造器去创建，我们就可以根据实际需求控制线程池需要的任何参数，避免发生OOM异常。
11.线程池有哪些状态吗？
线程池有5种状态， 第1种，RUNNING，指的是线程池的初始化状态，可添加待执行的任务。 第2种，SHUTDOWN，指的是线程池处于待关闭状态，不接收新任务，仅处理已接收的任务。 第3种，STOP，指的是线程池立即关闭，不接收新的任务，放弃缓存队列中的任务并且中断正在处理的任务。 第4种，TIDYING，指的是线程池自主整理状态，我们可以调用 terminated() 方法进行线程池整理。 第5种，TERMINATED，指的是线程池终止状态。
12.线程池中使用到了阻塞队列，那你知道有哪些阻塞队列？
JDK7及以后一共有7种阻塞队列： 第1种，ArrayBlockingQueue ，由数组结构组成的有界阻塞队列。 第2种，LinkedBlockingQueue ，由链表结构组成的有界阻塞队列。 第3种，PriorityBlockingQueue ，支持优先级排序的无界阻塞队列。 第4种，DelayQueue，使用优先级队列实现的无界阻塞队列。 第5种，SynchronousQueue，不存储元素的阻塞队列。 第6种，LinkedTransferQueue，由链表结构组成的无界阻塞队列。 第7种，LinkedBlockingDeque，由链表结构组成的双向阻塞队列。 另外，Executors 中使用最多的是LinkedBlockingDeque，还用了SynchronousQueue。
13.线程池如何调优
(1)首先，根据不同的需求选择线程池，如果需要单线程顺序执行，使用SingleThreadExecutor，如果已知并发压力，使用FixedThreadPool，固定线程数的大小，执行时间小的任务，可以使用CachedThreadPool，创建可缓存的线程池，可以无限扩大线程池，可以灵活回收空闲线程，最多可容纳几万个线程，线程空余60s会被回收，需要后台执行周期任务的，可以使用ScheduledThreadPool，可以延时启动和定时启动线程池。
(2)如何确认线程池的最大线程数目，分CPU密集型和IO密集型，如果是CPU密集型或计算密集型，因为CPU的利用率高，核心线程数可设置为n(核数)+1，如果是IO密集型，CPU利用率不高，可多给几个线程数，来进行工作，核心线程数可设置为2n(核数)
14. 线程池中多线程的处理过程（最大核心是 5，最大线程数量 10，最大队列 10）；如果满了后，如何进行；核心线程最终会结束吗（一面的时候和面试官讨论过，面试官说核心线程也是会结束的，所以我就按照1 面的说的）
当allowCoreThreadTimeOut手动设置为true或者执行的run方法抛出异常，核心线程都会被销毁，但是后者还是会创建新的线程称呼来，前者则销毁什么都不做，关键在于allowCoreThreadTimeOut为true则下面代码直接返回，不在执行addWorker方法。
15.如何关闭线程？
1.设置退出标志，使线程正常退出，也就是当run()方法完成后线程终止 2.使用interrupt()方法中断线程 3.使用stop方法强行终止线程（不推荐使用，Thread.stop, Thread.suspend, Thread.resume 和Runtime.runFinalizersOnExit 这些终止线程运行的方法已经被废弃，使用它们是极端不安全的！）
16.线程进程区别
1 进程是执行着的程序，线程是进程内的一个执行序列。一个进程可以拥有多个线程。 2 进程是资源分配的最小单元，线程是执行调度的最小单元。进程拥有独立的资源，多个线程间共享这些资源。 3 进程间通信代价较大，线程间通信代价小。
17.线上服务器最多可以创建多少个线程？
线程数量=（机器本身可用内存-JVM分配的堆内存）/Xss的值，比如我们的容器本身大小是8G,堆大小是4096M,走-Xss默认值，可以得出 最大线程数量：4096个。
根据计算公式，得出如下结论： 结论1：jvm堆越大，系统创建的线程数量越小。 结论2：当-Xss的值越小，可生成线程数量越多。
18.线程的状态有哪些？
New：新创建的线程，尚未执行； Runnable：运行中的线程，正在执行run()方法的Java代码； Blocked：运行中的线程，因为某些操作被阻塞而挂起； Waiting：运行中的线程，因为某些操作在等待中； Timed Waiting：运行中的线程，因为执行sleep()方法正在计时等待； Terminated：线程已终止，因为run()方法执行完毕。
19.轻量级锁升级成重量级锁会有开销？有没有什么办法让锁不升级？上来就用重量级锁？
有额外的CAS操作开销，使用自旋会消耗CPU性能。
因为wait()方法调用过程中依赖于重量级锁中与对象关联的monitor，在调用wait()方法后monitor会把线程变为WAITING状态，所以才会强制升级为重量级锁。除此之外，调用hashCode方法时也会使偏向锁直接升级为重量级锁。
444
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
