Java多线程面试集锦

什么是线程？进程？协程？

进程

具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位.（比如一个qq程序就是一个进程或者多个进程），系统进行资源分配的最小单位.。进程比较重量，占据独立的内存，所以上下文进程间的切换开销（栈、寄存器、虚拟内存、文件句柄等）比较大，但相对比较稳定安全

线程

程序执行流的最小单元（操作系统可识别的最小执行和调度单位）。也可以理解线程是一个程序里面不同的执行路径。是为了提高cpu的利用率而设计的。线程间通信主要通过共享内存，上下文切换很快，资源开销较少，但相比进程不够稳定容易丢失数据。
线程是轻量级的进程，它们是共享在父进程拥有的资源下，每个线程在父进程的环境中顺序的独立的执行一个活动，每个CPU核心在同一时刻只能执行一个线程，尽管我们有时感觉自己的计算机同时开着多个任务，其实他们每个的执行都是走走停停的，CPU轮流给每个进程及线程分配时间。

协程（线程的线程）

协程是一种用户态的轻量级线程，协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈，直接操作栈则基本没有内核切换的开销，可以不加锁的访问全局变量，所以上下文的切换非常快。

什么是线程安全和线程不安全？

通俗的说：加锁的就是是线程安全的，不加锁的就是是线程不安全的

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

  一个线程安全的计数器类的同一个实例对象在被多个线程使用的情况下也不会出现计算失误。很显然你可以将集合类分成两组，线程安全和非线程安全的。 Vector 是用同步方法来实现线程安全的, 而和它相似的ArrayList不是线程安全的。

• 线程不安全
  线程不安全：就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据。
  如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。
  线程安全问题都是由全局变量及静态变量引起的。 若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则的话就可能影响线程安全。

什么是自旋锁？

自旋锁

是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。

它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，”自旋”一词就是因此而得名。

Java如何实现自旋锁

public class SpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    public void lock() {
        Thread current = Thread.currentThread();
        // 利用CAS
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}

lock() 方法利用的CAS，当第一个线程A获取锁的时候，能够成功获取到，不会进入while循环，如果此时线程A没有释放锁，另一个线程B又来获取锁，此时由于不满足CAS，所以就会进入while循环，不断判断是否满足CAS，直到A线程调用unlock方法释放了该锁。

自旋锁优缺点

• 缺点

  1. 如果某个线程持有锁的时间过长，就会导致其它等待获取锁的线程进入循环等待，消耗CPU。使用不当会造成CPU使用率极高。

  2. 上面Java实现的自旋锁不是公平的，即无法满足等待时间最长的线程优先获取锁。不公平的锁就会存在“线程饥饿”问题。

• 优点

  1. 自旋锁不会使线程状态发生切换，一直处于用户态，即线程一直都是active的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快
  2. 非自旋锁在获取不到锁的时候会进入阻塞状态，从而进入内核态，当获取到锁的时候需要从内核态恢复，需要线程上下文切换。 （线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能）

可重入的自旋锁和不可重入的自旋锁

上面那段代码，仔细分析一下就可以看出，它是不支持重入的，即当一个线程第一次已经获取到了该锁，在锁释放之前又一次重新获取该锁，第二次就不能成功获取到。由于不满足CAS，所以第二次获取会进入while循环等待，而如果是可重入锁，第二次也是应该能够成功获取到的。

而且，即使第二次能够成功获取，那么当第一次释放锁的时候，第二次获取到的锁也会被释放，而这是不合理的。

为了实现可重入锁，我们需要引入一个计数器，用来记录获取锁的线程数。

public class ReentrantSpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    private int count;
    public void lock() {
        Thread current = Thread.currentThread();
        if (current == cas.get()) { // 如果当前线程已经获取到了锁，线程数增加一，然后返回
            count++;
            return;
        }
        // 如果没获取到锁，则通过CAS自旋
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread cur = Thread.currentThread();
        if (cur == cas.get()) {
            if (count > 0) {// 如果大于0，表示当前线程多次获取了该锁，释放锁通过count减一来模拟
                count--;
            } else {// 如果count==0，可以将锁释放，这样就能保证获取锁的次数与释放锁的次数是一致的了。
                cas.compareAndSet(cur, null);
            }
        }
    }
}

自旋锁与互斥锁

• 自旋锁与互斥锁都是为了实现保护资源共享的机制。
• 无论是自旋锁还是互斥锁，在任意时刻，都最多只能有一个保持者。
• 获取互斥锁的线程，如果锁已经被占用，则该线程将进入睡眠状态；获取自旋锁的线程则不会睡眠，而是一直循环等待锁释放。

总结

• 自旋锁：线程获取锁的时候，如果锁被其他线程持有，则当前线程将循环等待，直到获取到锁。
• 自旋锁等待期间，线程的状态不会改变，线程一直是用户态并且是活动的(active)。
• 自旋锁如果持有锁的时间太长，则会导致其它等待获取锁的线程耗尽CPU。
• 自旋锁本身无法保证公平性，同时也无法保证可重入性。
• 基于自旋锁，可以实现具备公平性和可重入性质的锁。

参考： https://segmentfault.com/a/1190000015795906#articleHeader0

什么是Java内存模型？

VM包括两个子系统和两个组件。

两个子系统：

• Class loader（类装载）
  根据给定的全限定名类名(如：java.lang.Object)来装载class文件到Runtime data area中的method area。程序中可以extends java.lang.ClassLoader类来实现自己的Class loader。

• Execution engine（执行引擎）
  执行classes中的指令。任何JVM specification实现(JDK)的核心都是Execution engine，不同的JDK例如Sun的JDK和IBM的JDK好坏主要就取决于他们各自实现的Execution engine的好坏。

两个组件

• Native interface(本地接口)
  与native libraries交互，是其它编程语言交互的接口。当调用native方法的时候，就进入了一个全新的并且不再受虚拟机限制的世界，所以也很容易出现JVM无法控制的native heap OutOfMemory。

• Runtime data area（运行时数据区）
  这就是我们常说的JVM的内存。主要分为五个部分：

方法区

1. 有时候也成为永久代，在该区内很少发生垃圾回收，但是并不代表不发生GC，在这里进行的GC主要是对方法区里的常量池和对类型的卸载

2. 方法区主要用来存储已被虚拟机加载的类的信息、常量、静态变量和即时编译器编译后的代码等数据，方法区也称持久代（Permanent Generation）。

3. 该区域是被线程共享的。

4. 方法区里有一个运行时常量池，用于存放静态编译产生的字面量和符号引用。该常量池具有动态性，也就是说常量并不一定是编译时确定，运行时生成的常量也会存在这个常量池中。

虚拟机栈

1. 虚拟机栈也就是我们平常所称的栈内存, 它为java方法服务，每个方法在执行的时候都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接和方法出口等信息。

2. 虚拟机栈是线程私有的，它的生命周期与线程相同。

3. 局部变量表里存储的是基本数据类型、returnAddress类型（指向一条字节码指令的地址）和对象引用，这个对象引用有可能是指向对象起始地址的一个指针，也有可能是代表对象的句柄或者与对象相关联的位置。局部变量所需的内存空间在编译器间确定

4. 操作数栈的作用主要用来存储运算结果以及运算的操作数，它不同于局部变量表通过索引来访问，而是压栈和出栈的方式

5. 每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接. 动态链接就是将常量池中的符号引用在运行期转化为直接引用

6. 可通过参数-Xss设置栈容量

本地方法栈

本地方法栈和虚拟机栈类似，只不过本地方法栈为Native方法服务

堆

• Java堆是所有线程所共享的一块内存，在虚拟机启动时创建

• Java堆唯一的目的是存放对象实例，几乎所有的对象实例和数组都在这里创建，因此该区域经常发生垃圾回收操作

• 可通过参数 -Xms 和-Xmx设置

• Java堆为了便于更好的回收和分配内存，可以细分为：新生代和老年代；

  • 新生代：包括Eden区、From Survivor区、To Survivor区，系统默认大小Eden:Survivor=8:1。
  • 老年代：在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

程序计数器

内存空间小，字节码解释器工作时通过改变这个计数值可以选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理和线程恢复等功能都需要依赖这个计数器完成。该内存区域是唯一一个java虚拟机规范没有规定任何OOM情况的区域

什么是CAS？

介绍

CAS算法 即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数

• 需要读写的内存值 V
• 进行比较的值 A
• 拟写入的新值 B

当且仅当 V 的值等于 A 时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。

CAS 不通过JVM，直接利用java本地方 JNI（Java Native Interface为JAVA本地调用），直接调用CPU 的cmpxchg（汇编指令）指令。
利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法,实现原子操作。其它原子操作都是利用类似的特性完成的。

整个java.util.concurrent都是建立在CAS之上的，因此对于synchronized阻塞算法，J.U.C在性能上有了很大的提升。

CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。

CAS优点

确保对内存的读-改-写操作都是原子操作执行

CAS缺点

CAS虽然很高效的解决原子操作，但是CAS仍然存在三大问题。ABA问题，循环时间长开销大和只能保证一个共享变量的原子操作

总结

• 使用CAS在线程冲突严重时，会大幅降低程序性能；CAS只适合于线程冲突较少的情况使用。
• synchronized在jdk1.6之后，已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

什么是乐观锁和悲观锁？

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中 synchronized和 ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中 java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

使用场景

• 乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
• 悲观锁就比较合适多写的场景。多写的情况，一般会经常产生冲突，如果使用乐观锁，就会导致上层应用会不断的进行retry，这样反倒是降低了性能。

乐观锁常见的两种实现方式

乐观锁一般会使用版本号机制或CAS算法实现。

• 1. 版本号机制
     一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

举一个简单的例子：假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1. 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。

1. 在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。

2. 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。

3. 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

• 2. CAS算法
     即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数
     • 需要读写的内存值 V
     • 进行比较的值 A
     • 拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

乐观锁的缺点

• 1 ABA 问题
  如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 “ABA”问题。

  JDK 1.5 以后的 AtomicStampedReference类就提供了此种能力，其中的 compareAndSet方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

• 2 循环时间长开销大
  自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。 如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

• 3 只能保证一个共享变量的原子操作
  CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5开始，提供了 AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用 AtomicReference类把多个共享变量合并成一个共享变量来操作。

CAS与synchronized的使用情景

简单的来说CAS适用于写比较少的情况下（多读场景，冲突一般较少），synchronized适用于写比较多的情况下（多写场景，冲突一般较多）

1. 对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。

2. 对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

补充： Java并发编程这个领域中synchronized关键字一直都是元老级的角色，很久之前很多人都会称它为 “重量级锁” 。
但是，在JavaSE 1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的 偏向锁 *和 *轻量级锁 以及其它各种优化之后变得在某些情况下并不是那么重了。synchronized的底层实现主要依靠 Lock-Free 的队列，基本思路是 自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

什么是AQS？

简介

AbstractQueuedSynchronizer简称AQS，是一个用于构建锁和同步容器的框架。事实上concurrent包内许多类都是基于AQS构建，例如ReentrantLock，Semaphore，CountDownLatch，ReentrantReadWriteLock，FutureTask等。AQS解决了在实现同步容器时设计的大量细节问题。

AQS使用一个FIFO的队列表示排队等待锁的线程，队列头节点称作“哨兵节点”或者“哑节点”，它不与任何线程关联。其他的节点与等待线程关联，每个节点维护一个等待状态waitStatus。

CAS 原子操作在concurrent包的实现

参考 https://blog.52itstyle.com/archives/948/

由于java的CAS同时具有 volatile 读和volatile写的内存语义，因此Java线程之间的通信现在有了下面四种方式：

• A线程写volatile变量，随后B线程读这个volatile变量。
• A线程写volatile变量，随后B线程用CAS更新这个volatile变量。
• A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。
• A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，volatile变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。

如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：

• 首先，声明共享变量为volatile； 然后，使用CAS的原子条件更新来实现线程之间的同步；

• 同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。

AQS，非阻塞数据结构和原子变量类（Java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如下：

AQS实现

AQS没有锁之类的概念，它有个state变量，是个int类型，在不同场合有着不同含义。

AQS围绕state提供两种基本操作“获取”和“释放”，有条双向队列存放阻塞的等待线程，并提供一系列判断和处理方法，简单说几点：

• state是独占的，还是共享的；
• state被获取后，其他线程需要等待；
• state被释放后，唤醒等待线程；
• 线程等不及时，如何退出等待。

至于线程是否可以获得state，如何释放state，就不是AQS关心的了，要由子类具体实现。

例如ReentrantLocky用它表示线程重入锁的次数，Semaphore用它表示剩余的许可数量，FutureTask用它表示任务的状态。对state变量值的更新都采用CAS操作保证更新操作的原子性。

AbstractQueuedSynchronizer继承了AbstractOwnableSynchronizer，这个类只有一个变量：exclusiveOwnerThread，表示当前占用该锁的线程，并且提供了相应的get，set方法。

什么是原子操作？在Java Concurrent API中有哪些原子类(atomic classes)？

原子操作是指一个不受其他操作影响的操作任务单元。原子操作是在多线程环境下避免数据不一致必须的手段。

Atomic包一共提供了13个类，包含四种类型的原子更新方式，分别是：

基本类型

• AtomicBoolean
• AtomicInteger
• AtomicLong

数组类型

• AtomicIntegerArray
• AtomicLongArray
• AtomicReferenceArray

引用类型

• AtomicReference
• AtomicReferenceFieldUpdater
• AtomicMarkableReference

属性类型

• AtomicIntegeFeildUpdater
• AtomicLongFieldUpdater
• AtomicStampedRefernce

什么是Executors框架？

Executor框架同java.util.concurrent.Executor 接口在Java 5中被引入，是一个静态工具类。
Executor框架是一个根据一组执行策略调用，调度，执行和控制的异步任务的框架。

无限制的创建线程会引起应用程序内存溢出。所以创建一个线程池是个更好的的解决方案，因为可以限制线程的数量并且可以回收再利用这些线程。

利用Executors框架可以非常方便的创建一个线程池，Java通过Executors提供四种线程池，分别为：

• newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

• newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。

• newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。

• newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

什么是阻塞队列？如何使用阻塞队列来实现生产者-消费者模型？

什么是阻塞队列？

阻塞队列是一个在队列基础上又支持了两个附加操作的队列。

2个附加操作：

• 支持阻塞的插入方法
  队列满时，队列会阻塞插入元素的线程，直到队列不满。

• 支持阻塞的移除方法
  队列空时，获取元素的线程会等待队列变为非空。

几个关键方法
在阻塞队列不可用的时候，上述2个附加操作提供了四种处理方法

方法/处理方式	抛出异常	返回特殊值	一直阻塞	超时退出
插入方法	add(e)	offer(e)	put(e)	offer(e,time,unit)
移除方法	remove()	poll()	take()	poll(time,unit)
检查方法	element()	peek()	不可用	不可用

阻塞队列的应用场景

阻塞队列常用于生产者和消费者的场景，生产者是向队列里添加元素的线程，消费者是从队列里取元素的线程。简而言之，阻塞队列是生产者用来存放元素、消费者获取元素的容器。

java里的阻塞队列

JDK 7 提供了7个阻塞队列，如下

• 1、ArrayBlockingQueue 数组结构组成的有界阻塞队列。
  此队列按照先进先出（FIFO）的原则对元素进行排序，但是默认情况下不保证线程公平的访问队列，即如果队列满了，那么被阻塞在外面的线程对队列访问的顺序是不能保证线程公平（即先阻塞，先插入）的。

• 2、LinkedBlockingQueue一个由链表结构组成的有界阻塞队列
  此队列按照先出先进的原则对元素进行排序

• 3、PriorityBlockingQueue支持优先级的无界阻塞队列

• 4、DelayQueue支持延时获取元素的无界阻塞队列，即可以指定多久才能从队列中获取当前元素

• 5、SynchronousQueue不存储元素的阻塞队列，每一个put必须等待一个take操作，否则不能继续添加元素。并且他支持公平访问队列。

• 6、LinkedTransferQueue由链表结构组成的无界阻塞TransferQueue队列。相对于其他阻塞队列，多了tryTransfer和transfer方法

  1. transfer方法
     如果当前有消费者正在等待接收元素（take或者待时间限制的poll方法），transfer可以把生产者传入的元素立刻传给消费者。如果没有消费者等待接收元素，则将元素放在队列的tail节点，并等到该元素被消费者消费了才返回。
  2. tryTransfer方法
     用来试探生产者传入的元素能否直接传给消费者。如果没有消费者在等待，则返回false。和上述方法的区别是该方法无论消费者是否接收，方法立即返回。而transfer方法是必须等到消费者消费了才返回。

• 7、LinkedBlockingDeque链表结构的双向阻塞队列，优势在于多线程入队时，减少一半的竞争。

什么是Callable和Future?

Callable 和 Future 是比较有趣的一对组合。当我们需要获取线程的执行结果时，就需要用到它们。Callable用于产生结果，Future用于获取结果。

Callable接口使用泛型去定义它的返回类型。Executors类提供了一些有用的方法去在线程池中执行Callable内的任务。由于Callable任务是并行的，必须等待它返回的结果。java.util.concurrent.Future对象解决了这个问题。

在线程池提交Callable任务后返回了一个Future对象，使用它可以知道Callable任务的状态和得到Callable返回的执行结果。Future提供了get()方法，等待Callable结束并获取它的执行结果。

什么是FutureTask?

FutureTask可用于异步获取执行结果或取消执行任务的场景。通过传入Runnable或者Callable的任务给FutureTask，直接调用其run方法或者放入线程池执行，之后可以在外部通过FutureTask的get方法异步获取执行结果。

• FutureTask非常适合用于耗时的计算，主线程可以在完成自己的任务后，再去获取结果。
• FutureTask还可以确保即使调用了多次run方法，它都只会执行一次Runnable或者Callable任务，或者通过cancel取消FutureTask的执行等。

高并发场景示例：
FutureTask在高并发环境下确保任务只执行一次

在很多高并发的环境下，往往我们只需要某些任务只执行一次。这种使用情景FutureTask的特性恰能胜任。举一个例子，假设有一个带key的连接池，当key存在时，即直接返回key对应的对象；当key不存在时，则创建连接。对于这样的应用场景，通常采用的方法为使用一个Map对象来存储key和连接池对应的对应关系，典型的代码如下面所示：

private Map<String, Connection> connectionPool = new HashMap<String, Connection>();
private ReentrantLock lock = new ReentrantLock();

public Connection getConnection(String key) {
    try {
        lock.lock();
        if (connectionPool.containsKey(key)) {
            return connectionPool.get(key);
        } else {
            //创建 Connection
            Connection conn = createConnection();
            connectionPool.put(key, conn);
            return conn;
        }
    } finally {
        lock.unlock();
    }
} //创建Connection 

private Connection createConnection() {
    return null;
}

在上面的例子中，我们通过加锁确保高并发环境下的线程安全，也确保了connection只创建一次，然而确牺牲了性能。
改用ConcurrentHash的情况下，几乎可以避免加锁的操作，性能大大提高，但是在高并发的情况下有可能出现Connection被创建多次的现象。这时最需要解决的问题就是当key不存在时，创建Connection的动作能放在connectionPool之后执行，这正是FutureTask发挥作用的时机，基于ConcurrentHashMap和FutureTask的改造代码如下：

private ConcurrentHashMap<String, FutureTask<Connection>> connectionPool =
        new ConcurrentHashMap<String, FutureTask<Connection>>();

public Connection getConnection(String key) throws Exception {
    FutureTask<Connection> connectionTask = connectionPool.get(key);
    if (connectionTask != null) {
        return connectionTask.get();
    } else {
        Callable<Connection> callable = new Callable<Connection>() {
            @Override
            public Connection call() throws
                    Exception {
                // TODO Auto-generated method stub 
                return createConnection();
            }
        };
        FutureTask<Connection> newTask = new FutureTask<Connection>(callable);
        connectionTask = connectionPool.putIfAbsent(key, newTask);
        if (connectionTask == null) {
            connectionTask = newTask;
            connectionTask.run();
        }
        return connectionTask.get();
    }
}

//创建Connection
private Connection createConnection() {
    return null;
}

经过这样的改造，可以避免由于并发带来的多次创建连接及锁的出现。

什么是同步容器和并发容器的实现？

一、同步容器

主要代表有Vector和HashTable，以及Collections.synchronizedXxx等。 锁的粒度为当前对象整体。 迭代器是及时失败的，即在迭代的过程中发现被修改，就会抛出ConcurrentModificationException。

二、并发容器

主要代表有ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentSkipListMap、ConcurrentSkipListSet。 锁的粒度是分散的、细粒度的，即读和写是使用不同的锁。 迭代器具有弱一致性，即可以容忍并发修改，不会抛出ConcurrentModificationException。

• ConcurrentHashMap
  采用分离锁技术，同步容器中，是一个容器一个锁，但在ConcurrentHashMap中，会将hash表的数组部分分成若干段，每段维护一个锁，以达到高效的并发访问；

三、阻塞队列

主要代表有LinkedBlockingQueue、ArrayBlockingQueue、PriorityBlockingQueue(Comparable, Comparator)、SynchronousQueue。 提供了可阻塞的put和take方法，以及支持定时的offer和poll方法。 适用于生产者、消费者模式（线程池和工作队列-Executor），同时也是同步容器

四、双端队列

主要代表有ArrayDeque和LinkedBlockingDeque。
意义：正如阻塞队列适用于生产者消费者模式，双端队列同样适用与另一种模式，即工作密取。在生产者-消费者设计中，所有消费者共享一个工作队列，而在工作密取中，每个消费者都有各自的双端队列。 如果一个消费者完成了自己双端队列中的全部工作，那么他就可以从其他消费者的双端队列末尾秘密的获取工作。具有更好的可伸缩性，这是因为工作者线程不会在单个共享的任务队列上发生竞争。 在大多数时候，他们都只是访问自己的双端队列，从而极大的减少了竞争。当工作者线程需要访问另一个队列时，它会从队列的尾部而不是头部获取工作，因此进一步降低了队列上的竞争。 适用于：网页爬虫等任务中

五、比较及适用场景

• 如果不需要阻塞队列，优先选择ConcurrentLinkedQueue；
• 如果需要阻塞队列，队列大小固定优先选择ArrayBlockingQueue，队列大小不固定优先选择LinkedBlockingQueue；
• 如果需要对队列进行排序，选择PriorityBlockingQueue；
• 如果需要一个快速交换的队列，选择SynchronousQueue；
• 如果需要对队列中的元素进行延时操作，则选择DelayQueue。

什么是多线程？优缺点？

多线程：是指从软件或者硬件上实现多个线程的并发技术。

• 多线程的好处：
  使用多线程可以把程序中占据时间长的任务放到后台去处理，如图片、视屏的下载
  发挥多核处理器的优势，并发执行让系统运行的更快、更流畅，用户体验更好

• 多线程的缺点：

  1. 大量的线程降低代码的可读性；
  2. 更多的线程需要更多的内存空间
  3. 当多个线程对同一个资源出现争夺时候要注意线程安全的问题。

什么是多线程的上下文切换？

即使是单核CPU也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程时同时执行的，时间片一般是几十毫秒（ms）

上下文切换过程中，CPU会停止处理当前运行的程序，并保存当前程序运行的具体位置以便之后继续运行。

CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再次加载这个任务的状态。

从任务保存到再加载的过程就是一次上下文切换。

ThreadLocal的设计理念与作用？

Java中的ThreadLocal类允许我们创建只能被同一个线程读写的变量。因此，如果一段代码含有一个ThreadLocal变量的引用，即使两个线程同时执行这段代码，它们也无法访问到对方的ThreadLocal变量

InheritableThreadLocal

public static ThreadLocal<Integer> threadLocal = new InheritableThreadLocal<Integer>();

InheritableThreadLocal类是ThreadLocal类的子类。
ThreadLocal中每个线程拥有它自己的值，与ThreadLocal不同的是，InheritableThreadLocal允许一个线程以及该线程创建的所有子线程都可以访问它保存的值。

ThreadPool（线程池）用法与优势？

为什么要用线程池:

1. 减少了创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务。

2. 可以根据系统的承受能力，调整线程池中工作线线程的数目，防止因为消耗过多的内存，而把服务器累趴下(每个线程需要大约1MB内存，线程开的越多，消耗的内存也就越大，最后死机)。

3. 减少在创建和销毁线程上所花的时间以及系统资源的开销,如不使用线程池，有可能造成系统创建大量线程而导致消耗完系统内存

Java里面线程池的顶级接口是Executor，但是严格意义上讲Executor并不是一个线程池，而只是一个执行线程的工具。真正的线程池接口是ExecutorService。

new Thread 缺点

1. 每次new Thread新建对象性能差。

2. 线程缺乏统一管理，可能无限制新建线程，相互之间竞争，及可能占用过多系统资源导致死机或oom。

3. 缺乏更多功能，如定时执行、定期执行、线程中断。

Executors提供四种线程池

1. newCachedThreadPool
   创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

2. newFixedThreadPool
   创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。

3. newScheduledThreadPool
   创建一个定长线程池，支持定时及周期性任务执行。

4. newSingleThreadExecutor
   创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

ThreadPoolExecutor的构造函数

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
    if (corePoolSize < 0 ||
        maximumPoolSize <= 0 ||
        maximumPoolSize < corePoolSize ||
        keepAliveTime < 0)
        throw new IllegalArgumentException();
    if (workQueue == null || threadFactory == null || handler == null)
        throw new NullPointerException();
    this.acc = System.getSecurityManager() == null ?
            null :
            AccessController.getContext();
    this.corePoolSize = corePoolSize;
    this.maximumPoolSize = maximumPoolSize;
    this.workQueue = workQueue;
    this.keepAliveTime = unit.toNanos(keepAliveTime);
    this.threadFactory = threadFactory;
    this.handler = handler;
}

• 参数：

  • corePoolSize核心线程数大小，当线程数<corepoolsize ，会创建线程执行

  • maximumPoolSize 最大线程数， 当线程数 >= corePoolSize的时候，会把runnable放入workQueue中

  • keepAliveTime 保持存活时间，当线程数大于corePoolSize的空闲线程能保持的最大时间。

  • unit 时间单位

  • workQueue 保存任务的阻塞队列

  • threadFactory 创建线程的工厂

  • handler 拒绝策略

• 任务执行顺序：

  • 当线程数小于corePoolSize时，创建线程执行任务。

  • 当线程数大于等于corePoolSize并且workQueue没有满时，放入workQueue中

  • 线程数大于等于corePoolSize并且当workQueue满时，新任务新建线程运行，线程总数要小于maximumPoolSize

  • 当线程总数等于maximumPoolSize并且workQueue满了的时候执行handler的rejectedExecution。也就是拒绝策略。

• ThreadPoolExecutor默认有四个拒绝策略：

  • ThreadPoolExecutor.AbortPolicy() 直接抛出异常RejectedExecutionException

  • ThreadPoolExecutor.CallerRunsPolicy() 直接调用run方法并且阻塞执行

  • ThreadPoolExecutor.DiscardPolicy() 直接丢弃后来的任务

  • ThreadPoolExecutor.DiscardOldestPolicy() 丢弃在队列中队首的任务

当然可以自己继承 RejectedExecutionHandler 来写拒绝策略.

Synchronized和ReentrantLock的区别？

java在编写多线程程序时，为了保证线程安全，需要对数据同步，经常用到两种同步方式就是Synchronized和重入锁ReentrantLock。

基础知识

• 可重入锁
  可重入锁是指同一个线程可以多次获取同一把锁。ReentrantLock和synchronized都是可重入锁。

• 可中断锁
  可中断锁是指线程尝试获取锁的过程中，是否可以响应中断。synchronized是不可中断锁，而ReentrantLock则提供了中断功能。

• 公平锁与非公平锁
  公平锁是指多个线程同时尝试获取同一把锁时，获取锁的顺序按照线程达到的顺序，而非公平锁则允许线程“插队”。synchronized是非公平锁，而ReentrantLock的默认实现是非公平锁，但是也可以设置为公平锁。

• CAS操作(CompareAndSwap)
  CAS操作简单的说就是比较并交换。CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。CAS 有效地说明了“我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。”

Synchronized

synchronized是java内置的关键字，它提供了一种独占的加锁方式。synchronized的获取和释放锁由JVM实现，用户不需要显示的释放锁，非常方便。然而synchronized也有一定的局限性

例如：

1. 当线程尝试获取锁的时候，如果获取不到锁会一直阻塞；
2. 如果获取锁的线程进入休眠或者阻塞，除非当前线程异常，否则其他线程尝试获取锁必须一直等待。

ReentrantLock

ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成。

用法示例：

private Lock lock = new ReentrantLock();

public void test() {
    lock.lock();
    try {
        doSomeThing();
    } finally {
        lock.unlock();
    }
}

• lock() 如果获取了锁立即返回，如果别的线程持有锁，当前线程则一直处于休眠状态，直到获取锁

• tryLock() 如果获取了锁立即返回true，如果别的线程正持有锁，立即返回false；

• tryLock(long timeout,TimeUnit unit) 如果获取了锁定立即返回true，如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false；

• lockInterruptibly 如果获取了锁定立即返回，如果没有获取锁定，当前线程处于休眠状态，直到或者锁定，或者当前线程被别的线程中断

ReentrantLock特性

• 等待可中断避免，出现死锁的情况（如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false）

• 公平锁与非公平锁多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好

ReenTrantLock实现的原理：

简单来说，ReenTrantLock的实现是一种自旋锁，通过循环调用CAS操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。

总结

在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁) 后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。

Synchronized：

在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好。

ReentrantLock:

ReentrantLock用起来会复杂一些。在基本的加锁和解锁上，两者是一样的，所以无特殊情况下，推荐使用synchronized。ReentrantLock的优势在于它更灵活、更强大，增加了轮训、超时、中断等高级功能。

ReentrantLock默认使用非公平锁是基于性能考虑，公平锁为了保证线程规规矩矩地排队，需要增加阻塞和唤醒的时间开销。如果直接插队获取非公平锁，跳过了对队列的处理，速度会更快。

Semaphore有什么作用？

Semaphore就是一个信号量，它的作用是限制某段代码块的并发数。Semaphore有一个构造函数，可以传入一个int型整数n，表示某段代码最多只有n个线程可以访问，如果超出了n，那么请等待，等到某个线程执行完毕这段代码块，下一个线程再进入。

由此可以看出如果Semaphore构造函数中传入的int型整数n=1，相当于变成了一个synchronized了。

// 阻塞
// 用来获取一个许可，若无许可能够获得，则会一直等待，直到获得许可
public void acquire() throws InterruptedException;
// 用来释放许可。注意，在释放许可之前，必须先获获得许可
public void release();
 
// 非阻塞
//尝试获取一个许可，若获取成功，则立即返回true，若获取失败，则立即返回false 
public boolean tryAcquire() {}; 
//尝试获取一个许可，若在指定的时间内获取成功，则立即返回true，否则则立即返回false 
public boolean tryAcquire(long timeout , TimeUnit unit ) throws InterruptedException {}; 
//尝试获取permits个许可，若获取成功，则立即返回true，若获取失败，则立即返回false 
public boolean tryAcquire(int permits ) {}; 
//尝试获取permits个许可，若在指定的时间内获取成功，则立即返回true 
public boolean tryAcquire(int permits , long timeout , TimeUnit unit ) throws InterruptedException {}; 
//得到当前可用的许可数目 
public int availablePermits();

示例:
假若一个工厂有5台机器，但是有8个工人，一台机器同时只能被一个工人使用，只有使用完了，其他工人才能继续使用。那么我们就可以通过Semaphore来实现：

public class Test{
	public static void main(String[] args) {
		int N = 8 ; 
		//工人数 
		Semaphore semaphore = new Semaphore(5); 
		//机器数目 
		for (int i = 0; i < N; i++) {
			new Worker(i, semaphore ).start (); 
		} 

		static class Worker extends Thread {
			private int num; 
			private Semaphore semaphore; 

			public Worker(int num, Semaphore semaphore){
				this.num = num; 
				this.semaphore = semaphore; 
			} 

			@Override 
			public void run() {
				try {
					semaphore.acquire(); 
					System.out.println ("工人"+ this.num + "占用一个机器在生产..."); 
					Thread.sleep (2000 ); 
					System.out.println ("工人"+ this.num + "释放出机器"); 
					semaphore.release (); 
				} catch (InterruptedException e) {
					e.printStackTrace(); 
				} 
			} 
		} 
	}
}

Java Concurrency API中的Lock接口(Lock interface)是什么？对比同步它有什么优势？

Lock接口比同步方法和同步块提供了更具扩展性的锁操作。他们允许更灵活的结构，可以具有完全不同的性质，并且可以支持多个相关类的条件对象。

它的优势有：

• 可以使锁更公平
• 可以使线程在等待锁的时候响应中断
• 可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间
• 可以在不同的范围，以不同的顺序获取和释放锁

ReentrantReadWriteLock读写锁的使用？

Lock比传统线程模型中的synchronized方式更加面向对象，与生活中的锁类似，锁本身也应该是一个对象。两个线程执行的代码片段要实现同步互斥的效果，它们必须用同一个Lock对象。

读写锁：分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由jvm自己控制的，你只要上好相应的锁即可。

如果你的代码只读数据，可以很多人同时读，但不能同时写，那就上读锁；
如果你的代码修改数据，只能有一个人在写，且不能同时读取，那就上写锁。
总之，读的时候上读锁，写的时候上写锁！

ReentrantReadWriteLock会使用两把锁来解决问题，一个读锁，一个写锁

线程进入读锁的前提条件：

• 没有其他线程的写锁

• 没有写请求或者有写请求，但调用线程和持有锁的线程是同一个

线程进入写锁的前提条件：

• 没有其他线程的读锁

• 没有其他线程的写锁

注意点：

• 读锁的重入是允许多个申请读操作的线程的，而写锁同时只允许单个线程占有，该线程的写操作可以重入。

• 如果一个线程占有了写锁，在不释放写锁的情况下，它还能占有读锁，即写锁降级为读锁。

• 对于同时占有读锁和写锁的线程，如果完全释放了写锁，那么它就完全转换成了读锁，以后的写操作无法重入，在写锁未完全释放时写操作是可以重入的。

• 公平模式下无论读锁还是写锁的申请都必须按照AQS锁等待队列先进先出的顺序。非公平模式下读操作插队的条件是锁等待队列head节点后的下一个节点是SHARED型节点，写锁则无条件插队。

• 读锁不允许newConditon获取Condition接口，而写锁的newCondition接口实现方法同ReentrantLock。

CyclicBarrier和CountDownLatch的用法及区别？

CountDownLatch	CyclicBarrier
减计数方式	加计数方式
计算为0时释放所有等待的线程	计数达到指定值时释放所有等待线程
计数为0时，无法重置	计数达到指定值时，计数置为0重新开始
调用countDown()方法计数减一，调用await()方法只进行阻塞，对计数没任何影响	调用await()方法计数加1，若加1后的值不等于构造方法的值，则线程阻塞
不可重复利用	可重复利用

LockSupport工具？

1、LockSupport基本介绍与基本使用

LockSupport是JDK中比较底层的类，用来创建锁和其他同步工具类的基本线程阻塞。java锁和同步器框架的核心 AQS: AbstractQueuedSynchronizer，就是通过调用 LockSupport .park()和 LockSupport .unpark()实现线程的阻塞和唤醒 的。

LockSupport 很类似于二元信号量(只有1个许可证可供使用)，如果这个许可还没有被占用，当前线程获取许可并继 续 执行；如果许可已经被占用，当前线 程阻塞，等待获取许可。

全部操作：

• park()/park(Object)
  等待通行准许。

• parkNanos(long)/parkNanos(Object, long)
  在指定运行时间（即相对时间）内，等待通行准许。

• parkUntil(long)/parkUntil(Object, long)
  在指定到期时间（即绝对时间）内，等待通行准许。

• unpark(Thread)
  发放通行准许或提前发放。（注：不管提前发放多少次，只用于一次性使用。）

• getBlocker(Thread)
  进入等待通行准许时，所提供的对象。

主要用途：

当前线程需要唤醒另一个线程，但是只确定它会进入阻塞，但不确定它是否已经进入阻塞，因此不管是否已经进入阻塞，还是准备进入阻塞，都将发放一个通行准许。

Condition接口及其实现原理？

• 在java.util.concurrent包中，有两个很特殊的工具类，Condition和ReentrantLock，使用过的人都知道，ReentrantLock（重入锁）是jdk的concurrent包提供的一种独占锁的实现

• 我们知道在线程的同步时可以使一个线程阻塞而等待一个信号，同时放弃锁使其他线程可以能竞争到锁
  在synchronized中我们可以使用Object的wait()和notify方法实现这种等待和唤醒

• 但是在Lock中怎么实现这种wait和notify呢？
  答案是Condition，学习Condition主要是为了方便以后学习blockqueue和concurrenthashmap的源码，同时也进一步理解ReentrantLock。Condition是一个多线程间协调通信的工具类，使得某个，或者某些线程一起等待某个条件（Condition）,只有当该条件具备( signal 或者 signalAll方法被带调用)时 ，这些等待线程才会被唤醒，从而重新争夺锁。

Fork/Join框架的理解?

Oracle的官方给出的定义是：Fork/Join框架是一个实现了ExecutorService接口的多线程处理器。它可以把一个大的任务划分为若干个小的任务并发执行，充分利用可用的资源，进而提高应用的执行效率。

我们再通过Fork和Join这两个单词来理解下Fork/Join框架，
Fork就是把一个大任务切分为若干子任务并行的执行，
Join就是合并这些子任务的执行结果，最后得到这个大任务的结果。

工作窃取算法

工作窃取算法是指线程从其他任务队列中窃取任务执行（可能你会很诧异，这个算法有什么用。待会你就知道了）。

考虑下面这种场景：
有一个很大的计算任务，为了减少线程的竞争，会将这些大任务切分为小任务并分在不同的队列等待执行，然后为每个任务队列创建一个线程执行队列的任务。那么问题来了，有的线程可能很快就执行完了，而其他线程还有任务没执行完，执行完的线程与其空闲下来不如帮助其他线程执行任务，这样也能加快执行进程。所以，执行完的空闲线程从其他队列的尾部窃取任务执行，而被窃取任务的线程则从队列的头部取任务执行（这里使用了双端队列，既不影响被窃取任务的执行过程又能加快执行进度）。

从以上的介绍中，能够发现工作窃取算法的优点是充分利用线程提高并行执行的进度。当然缺点是在某些情况下仍然存在竞争，比如双端队列只有一个任务需要执行的时候

使用Fork/Join框架两步：

• 分割任务：首先需要创建一个ForkJoin任务，执行该类的fork方法可以对任务不断切割，直到分割的子任务足够小

• 合并任务执行结果：子任务执行的结果同一放在一个队列中，通过启动一个线程从队列中取执行结果。

Fork/Join实现了ExecutorService，所以它的任务也需要放在线程池中执行。它的不同在于它使用了工作窃取算法，空闲的线程可以从满负荷的线程中窃取任务来帮忙执行。

示例：

import java.util.concurrent.ExecutionException;
import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.ForkJoinTask;
import java.util.concurrent.RecursiveTask;

public class CountTask extends RecursiveTask<Integer>{

    //阈值
    private static final int THRESHOLD = 2;
    //起始值
    private int start;
    //结束值
    private int end;

    public CountTask(int start, int end) {
        this.start = start;
        this.end = end;
    }


    @Override
    protected Integer compute() {
        boolean compute = (end - start) <= THRESHOLD;
        int res = 0;
        if (compute){
            for (int i = start; i <= end; i++){
                res += i;
            }
        }else {
            //如果长度大于阈值，则分割为小任务
            int mid = (start + end) / 2;
            CountTask task1 = new CountTask(start,mid);
            CountTask task2 = new CountTask(mid + 1, end);
            //计算小任务的值
            task1.fork();
            task2.fork();
            //得到两个小任务的值
            int task1Res = task1.join();
            int task2Res = task2.join();
            res = task1Res + task2Res;
        }
        return res;
    }

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        ForkJoinPool pool = new ForkJoinPool();
        CountTask task = new CountTask(1,5);
        ForkJoinTask<Integer> submit = pool.submit(task);
        System.out.println("Final result:" + submit.get());
    }
}

代码中使用了FokJoinTask，其与一般任务的区别在于它需要实现compute方法，在方法需要判断任务是否在阈值区间内，如果不是则需要把任务切分到足够小，直到能够进行计算。

每个被切分的子任务又会重新进入compute方法，再继续判断是否需要继续切分，如果不需要则直接得到子任务执行的结果，如果需要的话则继续切分，如此循环，直到调用join方法得到最终的结果。

wait()和sleep()的区别?

• sleep()
  方法是线程类（Thread）的静态方法，让调用线程进入睡眠状态，让出执行机会给其他线程，等到休眠时间结束后，线程进入就绪状态和其他线程一起竞争cpu的执行时间。

  因为sleep() 是static静态的方法，他不能改变对象的机锁，当一个synchronized块中调用了sleep() 方法，线程虽然进入休眠，但是对象的机锁没有被释放，其他线程依然无法访问这个对象。

• wait()
  wait()是Object类的方法，当一个线程执行到wait方法时，它就进入到一个和该对象相关的等待池，同时释放对象的机锁，使得其他线程能够访问，可以通过notify，notifyAll方法来唤醒等待的线程

线程的五个状态（五种状态，创建、就绪、运行、阻塞和死亡）?

start()方法和run()方法的区别？

每个线程都是通过某个特定Thread对象所对应的方法run()来完成其操作的，方法run()称为线程体。通过调用Thread类的start()方法来启动一个线程。

• start()
  启动一个线程，真正实现了多线程运行。这时无需等待run方法体代码执行完毕，可以直接继续执行下面的代码；
  这时此线程是处于就绪状态， 并没有运行。 然后通过此Thread类调用方法run()来完成其运行状态， 这里方法run()称为线程体，它包含了要执行的这个线程的内容， Run方法运行结束， 此线程终止。然后CPU再调度其它线程。

• run()
  方法是在本线程里的，只是线程里的一个函数,而不是多线程的。
  如果直接调用run(),其实就相当于是调用了一个普通函数而已，直接待用run()方法必须等待run()方法执行完毕才能执行下面的代码，所以执行路径还是只有一条，根本就没有线程的特征，所以在多线程执行时要使用start()方法而不是run()方法。

Runnable接口和Callable接口的区别？

• Runnable接口中的run()方法的返回值是void，它做的事情只是纯粹地去执行run()方法中的代码而已；

• Callable接口中的call()方法是有返回值的，是一个泛型，和Future、FutureTask配合可以用来获取异步执行的结果。

Callable+Future/FutureTask却可以获取多线程运行的结果，可以在等待时间太长没获取到需要的数据的情况下取消该线程的任务，非常有用。

Runnable和Thread实现多线程的区别

Java中实现多线程有两种方法：继承Thread类、实现Runnable接口，在程序开发中只要是多线程，肯定永远以实现Runnable接口为主，因为实现Runnable接口相比继承Thread类有如下优势：

• 1、可以避免由于Java的单继承特性而带来的局限；

• 2、增强程序的健壮性，代码能够被多个线程共享，代码与数据是独立的；

• 3、适合多个相同程序代码的线程区处理同一资源的情况。

下面以典型的买票程序（基本都是以这个为例子）为例，来说明二者的区别。

首先通过继承Thread类实现，代码如下：

class MyThread extends Thread{
	private int ticket = 5;
	public void run(){
		for (int i=0;i<10;i++)
		{
			if(ticket > 0){
				System.out.println("ticket = " + ticket--);
			}
		}
	}
}
 
public class ThreadDemo{
	public static void main(String[] args){
		new MyThread().start();
		new MyThread().start();
		new MyThread().start();
	}
}

某次的执行结果如下：

从结果中可以看出，每个线程单独卖了5张票，即独立地完成了买票的任务，但实际应用中，比如火车站售票，需要多个线程去共同完成任务，在本例中，即多个线程共同买5张票。

下面是通过实现Runnable接口实现的多线程程序，代码如下：

class MyThread implements Runnable{
	private int ticket = 5;
	public void run(){
		for (int i=0;i<10;i++)
		{
			if(ticket > 0){
				System.out.println("ticket = " + ticket--);
			}
		}
	}
}
 
public class RunnableDemo{
	public static void main(String[] args){
		MyThread my = new MyThread();
		new Thread(my).start();
		new Thread(my).start();
		new Thread(my).start();
	}
}

某次的执行结果如下:

从结果中可以看出，三个线程一共卖了5张票，即它们共同完成了买票的任务，实现了资源的共享。

总结
如果一个类继承Thread，则不适合资源共享。但是如果实现了Runable接口的话，则很容易的实现资源共享。
实现Runnable接口比继承Thread类所具有的优势：

• 1）：适合多个相同的程序代码的线程去处理同一个资源

• 2）：可以避免java中的单继承的限制

• 3）：增加程序的健壮性，代码可以被多个线程共享，代码和数据独立

• 4）：线程池只能放入实现Runable或callable类线程，不能直接放入继承Thread的类

提醒一下大家：main方法其实也是一个线程。在java中所有的线程都是同时启动的，至于什么时候，哪个先执行，完全看谁先得到CPU的资源。

在java中，每次程序运行至少启动2个线程。一个是main线程，一个是垃圾收集线程。因为每当使用java命令执行一个类的时候，实际上都会启动一个JVM，每一个JVM实例就是在操作系统中启动了一个进程。

volatile关键字的作用？

volatile关键字的作用主要有两个：

• （1）多线程主要围绕可见性和原子性两个特性而展开，使用volatile关键字修饰的变量，保证了其在多线程之间的可见性，即每次读取到volatile变量，一定是最新的数据;

• （2）代码底层执行是Java代码–>字节码–>根据字节码执行对应的C/C++代码–>C/C++代码被编译成汇编语言–>和硬件电路交互，现实中，为了获取更好的性能JVM可能会对指令进行重排序，多线程下可能会出现一些意想不到的问题。使用volatile则会对禁止语义重排序，当然这也一定程度上降低了代码执行效率;

从实践角度而言，volatile的一个重要作用就是和CAS结合，保证了原子性.

Java中如何获取到线程dump文件？

死循环、死锁、阻塞、页面打开慢等问题，打线程dump是最好的解决问题的途径。所谓线程dump也就是线程堆栈，获取到线程堆栈有两步：

• （1）获取到线程的pid，可以通过使用jps命令，在Linux环境下还可以使用ps -ef | grep java

• （2）打印线程堆栈，可以通过使用jstack pid命令，在Linux环境下还可以使用kill -3 pid

另外提一点，Thread类提供了一个getStackTrace()方法也可以用于获取线程堆栈。
这是一个实例方法，因此此方法是和具体线程实例绑定的，每次获取获取到的是具体某个线程当前运行的堆栈，

线程和进程有什么区别？

• 进程是系统进行资源分配的基本单位，有独立的内存地址空间

• 线程是CPU独立运行和独立调度的基本单位，没有单独地址空间，有独立的栈，局部变量，寄存器， 程序计数器等。

• 创建进程的开销大，包括创建虚拟地址空间等需要大量系统资源

• 创建线程开销小，基本上只有一个内核对象和一个堆栈。

• 一个进程无法直接访问另一个进程的资源；同一进程内的多个线程共享进程的资源。

• 进程切换开销大，线程切换开销小；进程间通信开销大，线程间通信开销小。

• 线程属于进程，不能独立执行。每个进程至少要有一个线程，成为主线程

线程实现的方式有几种（四种）？

• 继承Thread类，重写run方法

• 实现Runnable接口，重写run方法，实现Runnable接口的实现类的实例对象作为Thread构造函数的target

• 实现Callable接口通过FutureTask包装器来创建Thread线程

  FutureTask<Object> oneTask = new FutureTask<Object>(oneCallable);

• 通过线程池创建线程

  ExecutorService executorService = Executors.newFixedThreadPool(5);
  executorService.execute(new RunnableTask());

高并发、任务执行时间短的业务怎样使用线程池？并发不高、任务执行时间长的业务怎样使用线程池？并发高、业务执行时间长的业务怎样使用线程池？

• （1）高并发、任务执行时间短的业务，线程池线程数可以设置为CPU核数+1，减少线程上下文的切换

• （2）并发不高、任务执行时间长的业务要区分开看：

  a）假如是业务时间长集中在IO操作上，也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来，可以加大线程池中的线程数目，让CPU处理更多的业务

  b）假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，和（1）一样吧，线程池中的线程数设置得少一些，减少线程上下文的切换

• （3）并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，增加服务器是第二步，至于线程池的设置，设置参考（2）。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件对任务进行拆分和解耦。

锁的等级：方法锁、对象锁、类锁?

1. 通过在方法声明中加入 synchronized关键字来声明 synchronized 方法

synchronized 方法控制对类成员变量的访问：
每个类实例对应一把锁，每个 synchronized 方法都必须获得调用该方法的类实例的锁方能执行，否则所属线程阻塞，方法一旦执行，就独占该锁，直到从该方法返回时才将锁释放，此后被阻塞的线程方能获得该锁，重新进入可执行状态。

这种机制确保了同一时刻对于每一个类实例，其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态，从而有效避免了类成员变量的访问冲突。

2. 对象锁（synchronized修饰方法或代码块）

当一个对象中有synchronized method或synchronized block的时候调用此对象的同步方法或进入其同步区域时，就必须先获得对象锁。如果此对象的对象锁已被其他调用者占用，则需要等待此锁被释放。（方法锁也是对象锁） 　　 　　　

java的所有对象都含有1个互斥锁，这个锁由JVM自动获取和释放。线程进入synchronized方法的时候获取该对象的锁，当然如果已经有线程获取了这个对象的锁，那么当前线程会等待；synchronized方法正常返回或者抛异常而终止，JVM会自动释放对象锁。这里也体现了用synchronized来加锁的1个好处，方法抛异常的时候，锁仍然可以由JVM来自动释放。

3. 类锁(synchronized 修饰静态的方法或代码块)

由于一个class不论被实例化多少次，其中的静态方法和静态变量在内存中都只有一份。所以，一旦一个静态的方法被申明为synchronized。此类所有的实例化对象在调用此方法，共用同一把锁，我们称之为类锁。 　

对象锁是用来控制实例方法之间的同步，类锁是用来控制静态方法（或静态变量互斥体）之间的同步

如果同步块内的线程抛出异常会发生什么？

无论你的同步块是正常还是异常退出的，里面的线程都由JVM来自动释放锁，所以对比锁接口我更喜欢同步块，因为它不用我花费精力去释放锁，该功能可以在finally block里释放锁实现。

并发编程（concurrency）并行编程（parallellism）有什么区别？

并发和并行是：

1. 解释一：并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。

2. 解释二：并行是在不同实体上的多个事件，并发是在同一实体上的多个事件。

3. 解释三：在一台处理器上“同时”处理多个任务，在多台处理器上同时处理多个任务。如hadoop分布式集群

所以并发编程的目标是充分的利用处理器的每一个核，以达到最高的处理性能。

如何在两个线程之间共享数据?

• 通过在线程之间共享对象, 然后通过wait/notify/notifyAll、await/signal/signalAll进行唤起和等待，比方说阻塞队列BlockingQueue就是为线程之间共享数据而设计的；

• Exchanger 用于进行线程间数据交换；

生产者消费者模型的作用是什么?

这个问题很理论，但是很重要：

• （1）通过平衡生产者的生产能力和消费者的消费能力来提升整个系统的运行效率，这是生产者消费者模型最重要的作用

• （2）解耦，这是生产者消费者模型附带的作用，解耦意味着生产者和消费者之间的联系少，联系越少越可以独自发展而不需要收到相互的制约

怎么唤醒一个阻塞的线程?

• 如果线程是因为调用了wait()、sleep()或者join()方法而导致的阻塞，可以中断线程，并且通过抛出InterruptedException来唤醒它；

• 如果线程遇到了IO阻塞，无能为力，因为IO是操作系统实现的，Java代码并没有办法直接接触到操作系统。

Java中用到的线程调度算法是什么

抢占式。
一个线程用完CPU之后，操作系统会根据线程优先级、线程饥饿情况等数据算出一个总的优先级并分配下一个时间片给某个线程执行。

单例模式的线程安全性?

首先要说的是单例模式的线程安全意味着：某个类的实例在多线程环境下只会被创建一次出来。单例模式有很多种的写法，我总结一下：

（1）饿汉式单例模式的写法：线程安全

（2）懒汉式单例模式的写法：非线程安全

（3）双检锁单例模式的写法：线程安全

同步方法和同步块，哪个是更好的选择?

同步块是更好的选择，因为它不会锁住整个对象（当然也可以让它锁住整个对象）。

同步方法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们停止执行并需要等待获得这个对象上的锁。

public class SyncObj{
    // 同步方法会锁住整个对象
    public synchronized void showA(){
        System.out.println("showA..");
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public void showB() {
        // 同步块
        synchronized (this) {
            System.out.println("showB..");
        }
    }
}

如何检测死锁？怎么预防死锁？

死锁
是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁。通俗地讲就是两个或多个进程被无限期地阻塞、相互等待的一种状态

死锁产生的原因？

• 1.因竞争资源发生死锁 现象：系统中供多个进程共享的资源的数目不足以满足全部进程的需要时，就会引起对诸资源的竞争而发生死锁现象

• 2.进程推进顺序不当发生死锁

• 死锁的四个必要条件：

  • 互斥条件：进程对所分配到的资源不允许其他进程进行访问，若其他进程访问该资源，只能等待，直至占有该资源的进程使用完成后释放该资源

  • 请求和保持条件：进程获得一定的资源之后，又对其他资源发出请求，但是该资源可能被其他进程占有，此事请求阻塞，但又对自己获得的资源保持不放

  • 不可剥夺条件：是指进程已获得的资源，在未完成使用之前，不可被剥夺，只能在使用完后自己释放

  • 环路等待条件：是指进程发生死锁后，若干进程之间形成一种头尾相接的循环等待资源关系
    这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之
    一不满足，就不会发生死锁。

• 检测死锁
  有两个容器，一个用于保存线程正在请求的锁，一个用于保存线程已经持有的锁。每次加锁之前都会做如下检测:

  • 检测当前正在请求的锁是否已经被其它线程持有,如果有，则把那些线程找出来
  • 遍历第一步中返回的线程，检查自己持有的锁是否正被其中任何一个线程请求，如果第二步返回真,表示出现了死锁

• 死锁的解除与预防：
  理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和
  解除死锁。

  所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确
  定资源的合理分配算法，避免进程永久占据系统资源。

  此外，也要防止进程在处于等待状态的情况下占用资源。因此，对资源的分配要给予合理的规划。

转载：
想进大厂？50个多线程面试题，你会多少？（一）
想进大厂？50个多线程面试题，你会多少？（二）