Java 并发进阶常见面试题总结

 

Java 并发进阶常见面试题总结

1. synchronized 关键字

1.1. 说一说本身对于 synchronized 关键字的了解

synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized关键字能够保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

另外，在 Java 早期版本中，synchronized属于重量级锁，效率低下，由于监视器锁（monitor）是依赖于底层的操做系统的 Mutex Lock 来实现的，Java 的线程是映射到操做系统的原生线程之上的。若是要挂起或者唤醒一个线程，都须要操做系统帮忙完成，而操做系统实现线程之间的切换时须要从用户态转换到内核态，这个状态之间的转换须要相对比较长的时间，时间成本相对较高，这也是为何早期的 synchronized 效率低的缘由。庆幸的是在 Java 6 以后 Java 官方对从 JVM 层面对synchronized 较大优化，因此如今的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减小锁操做的开销。

1.2. 说说本身是怎么使用 synchronized 关键字，在项目中用到了吗

synchronized关键字最主要的三种使用方式：

• 修饰实例方法: 做用于当前对象实例加锁，进入同步代码前要得到当前对象实例的锁
• 修饰静态方法: 也就是给当前类加锁，会做用于类的全部对象实例，由于静态成员不属于任何一个实例对象，是类成员（ static 代表这是该类的一个静态资源，无论new了多少个对象，只有一份）。因此若是一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B须要调用这个实例对象所属类的静态 synchronized 方法，是容许的，不会发生互斥现象，由于访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
• 修饰代码块: 指定加锁对象，对给定对象加锁，进入同步代码库前要得到给定对象的锁。

总结： 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(); 这段代码实际上是分为三步执行：

1. 为 uniqueInstance 分配内存空间
2. 初始化 uniqueInstance
3. 将 uniqueInstance 指向分配的内存地址

可是因为 JVM 具备指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，可是在多线程环境下会致使一个线程得到尚未初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，所以返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。

使用 volatile 能够禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

1.3. 讲一下 synchronized 关键字的底层原理

synchronized 关键字底层原理属于 JVM 层面。

① synchronized 同步语句块的状况

public class SynchronizedDemo {  public void method() {  synchronized (this) {  System.out.println("synchronized 代码块");  }  } } 

经过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件，而后执行javap -c -s -v -l SynchronizedDemo.class。

从上面咱们能够看出：

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每一个Java对象的对象头中，synchronized 锁即是经过这种方式获取锁的，也是为何Java中任意对象能够做为锁的缘由) 的持有权。当计数器为0则能够成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，代表锁被释放。若是获取对象锁失败，那当前线程就要阻塞等待，直到锁被另一个线程释放为止。

② synchronized 修饰方法的的状况

public class SynchronizedDemo2 {  public synchronized void method() {  System.out.println("synchronized 方法");  } } 

synchronized 修饰的方法并无 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 经过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

1.4. 说说 JDK1.6 以后的synchronized 关键字底层作了哪些优化，能够详细介绍一下这些优化吗

JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减小锁操做的开销。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁能够升级不可降级，这种策略是为了提升得到锁和释放锁的效率。

关于这几种优化的详细信息能够查看笔主的这篇文章：https://gitee.com/SnailClimb/JavaGuide/blob/master/docs/java/Multithread/synchronized.md

1.5. 谈谈 synchronized和ReentrantLock 的区别

① 二者都是可重入锁

二者都是可重入锁。“可重入锁”概念是：本身能够再次获取本身的内部锁。好比一个线程得到了某个对象的锁，此时这个对象锁尚未释放，当其再次想要获取这个对象的锁的时候仍是能够获取的，若是不可锁重入的话，就会形成死锁。同一个线程每次获取锁，锁的计数器都自增1，因此要等到锁的计数器降低为0时才能释放锁。

② synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API

synchronized 是依赖于 JVM 实现的，前面咱们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了不少优化，可是这些优化都是在虚拟机层面实现的，并无直接暴露给咱们。ReentrantLock 是 JDK 层面实现的（也就是 API 层面，须要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），因此咱们能够经过查看它的源代码，来看它是如何实现的。

③ ReentrantLock 比 synchronized 增长了一些高级功能

相比synchronized，ReentrantLock增长了一些高级功能。主要来讲主要有三点：①等待可中断；②可实现公平锁；③可实现选择性通知（锁能够绑定多个条件）

• ReentrantLock提供了一种可以中断等待锁的线程的机制，经过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程能够选择放弃等待，改成处理其余事情。
• ReentrantLock能够指定是公平锁仍是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先得到锁。 ReentrantLock默认状况是非公平的，能够经过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来制定是不是公平的。
• synchronized关键字与wait()和notify()/notifyAll()方法相结合能够实现等待/通知机制，ReentrantLock类固然也能够实现，可是须要借助于Condition接口与newCondition() 方法。Condition是JDK1.5以后才有的，它具备很好的灵活性，好比能够实现多路通知功能也就是在一个Lock对象中能够建立多个Condition实例（即对象监视器），线程对象能够注册在指定的Condition中，从而能够有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify()/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例能够实现“选择性通知” ，这个功能很是重要，并且是Condition接口默认提供的。而synchronized关键字就至关于整个Lock对象中只有一个Condition实例，全部的线程都注册在它一个身上。若是执行notifyAll()方法的话就会通知全部处于等待状态的线程这样会形成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的全部等待线程。

若是你想使用上述功能，那么选择ReentrantLock是一个不错的选择。

④ 性能已不是选择标准

2. volatile关键字

2.1. 讲一下Java内存模型

在 JDK1.2 以前，Java的内存模型实现老是从主存（即共享内存）读取变量，是不须要进行特别的注意的。而在当前的 Java 内存模型下，线程能够把变量保存本地内存（好比机器的寄存器）中，而不是直接在主存中进行读写。这就可能形成一个线程在主存中修改了一个变量的值，而另一个线程还继续使用它在寄存器中的变量值的拷贝，形成数据的不一致。

要解决这个问题，就须要把变量声明为volatile，这就指示 JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。

说白了， volatile 关键字的主要做用就是保证变量的可见性而后还有一个做用是防止指令重排序。

2.2. 说说 synchronized 关键字和 volatile 关键字的区别

synchronized关键字和volatile关键字比较

• volatile关键字是线程同步的轻量级实现，因此volatile性能确定比synchronized关键字要好。可是volatile关键字只能用于变量而synchronized关键字能够修饰方法以及代码块。synchronized关键字在JavaSE1.6以后进行了主要包括为了减小得到锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各类优化以后执行效率有了显著提高，实际开发中使用 synchronized 关键字的场景仍是更多一些。
• 多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞
• volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字二者都能保证。
• volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。

3. ThreadLocal

3.1. ThreadLocal简介

一般状况下，咱们建立的变量是能够被任何一个线程访问并修改的。若是想实现每个线程都有本身的专属本地变量该如何解决呢？ JDK中提供的ThreadLocal类正是为了解决这样的问题。 ThreadLocal类主要解决的就是让每一个线程绑定本身的值，能够将ThreadLocal类形象的比喻成存放数据的盒子，盒子中能够存储每一个线程的私有数据。

若是你建立了一个ThreadLocal变量，那么访问这个变量的每一个线程都会有这个变量的本地副本，这也是ThreadLocal变量名的由来。他们可使用 get（） 和 set（） 方法来获取默认值或将其值更改成当前线程所存的副本的值，从而避免了线程安全问题。

再举个简单的例子：

好比有两我的去宝屋收集宝物，这两个共用一个袋子的话确定会产生争执，可是给他们两我的每一个人分配一个袋子的话就不会出现这样的问题。若是把这两我的比做线程的话，那么ThreadLocal就是用来避免这两个线程竞争的。

3.2. ThreadLocal示例

相信看了上面的解释，你们已经搞懂 ThreadLocal 类是个什么东西了。

import java.text.SimpleDateFormat; import java.util.Random;  public class ThreadLocalExample implements Runnable{   // SimpleDateFormat 不是线程安全的，因此每一个线程都要有本身独立的副本  private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));   public static void main(String[] args) throws InterruptedException {  ThreadLocalExample obj = new ThreadLocalExample();  for(int i=0 ; i<10; i++){  Thread t = new Thread(obj, ""+i);  Thread.sleep(new Random().nextInt(1000));  t.start();  }  }   @Override  public void run() {  System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());  try {  Thread.sleep(new Random().nextInt(1000));  } catch (InterruptedException e) {  e.printStackTrace();  }  //formatter pattern is changed here by thread, but it won't reflect to other threads  formatter.set(new SimpleDateFormat());   System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());  }  } 

Output:

Thread Name= 0 default Formatter = yyyyMMdd HHmm
Thread Name= 0 formatter = yy-M-d ah:mm Thread Name= 1 default Formatter = yyyyMMdd HHmm Thread Name= 2 default Formatter = yyyyMMdd HHmm Thread Name= 1 formatter = yy-M-d ah:mm Thread Name= 3 default Formatter = yyyyMMdd HHmm Thread Name= 2 formatter = yy-M-d ah:mm Thread Name= 4 default Formatter = yyyyMMdd HHmm Thread Name= 3 formatter = yy-M-d ah:mm Thread Name= 4 formatter = yy-M-d ah:mm Thread Name= 5 default Formatter = yyyyMMdd HHmm Thread Name= 5 formatter = yy-M-d ah:mm Thread Name= 6 default Formatter = yyyyMMdd HHmm Thread Name= 6 formatter = yy-M-d ah:mm Thread Name= 7 default Formatter = yyyyMMdd HHmm Thread Name= 7 formatter = yy-M-d ah:mm Thread Name= 8 default Formatter = yyyyMMdd HHmm Thread Name= 9 default Formatter = yyyyMMdd HHmm Thread Name= 8 formatter = yy-M-d ah:mm Thread Name= 9 formatter = yy-M-d ah:mm

从输出中能够看出，Thread-0已经改变了formatter的值，但仍然是thread-2默认格式化程序与初始化值相同，其余线程也同样。

上面有一段代码用到了建立 ThreadLocal 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，若是你写了下面这段代码的话，IDEA会提示你转换为Java8的格式(IDEA真的不错！)。由于ThreadLocal类在Java 8中扩展，使用一个新的方法withInitial()，将Supplier功能接口做为参数。

 private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){  @Override  protected SimpleDateFormat initialValue()  {  return new SimpleDateFormat("yyyyMMdd HHmm");  }  };

3.3. ThreadLocal原理

从 Thread类源代码入手。

public class Thread implements Runnable {  ...... //与此线程有关的ThreadLocal值。由ThreadLocal类维护 ThreadLocal.ThreadLocalMap threadLocals = null;  //与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;  ...... }

从上面Thread类 源代码能够看出Thread 类中有一个 threadLocals 和 一个 inheritableThreadLocals 变量，它们都是 ThreadLocalMap 类型的变量,咱们能够把 ThreadLocalMap 理解为ThreadLocal 类实现的定制化的 HashMap。默认状况下这两个变量都是null，只有当前线程调用 ThreadLocal 类的 set或get方法时才建立它们，实际上调用这两个方法的时候，咱们调用的是ThreadLocalMap类对应的 get()、set() 方法。

ThreadLocal类的set()方法

    public void set(T value) {  Thread t = Thread.currentThread();  ThreadLocalMap map = getMap(t);  if (map != null)  map.set(this, value);  else  createMap(t, value);  }  ThreadLocalMap getMap(Thread t) {  return t.threadLocals;  }

经过上面这些内容，咱们足以经过猜想得出结论：最终的变量是放在了当前线程的 ThreadLocalMap 中，并非存在 ThreadLocal 上，ThreadLocal 能够理解为只是ThreadLocalMap的封装，传递了变量值。 ThrealLocal 类中能够经过Thread.currentThread()获取到当前线程对象后，直接经过getMap(Thread t)能够访问到该线程的ThreadLocalMap对象。

每一个Thread中都具有一个ThreadLocalMap，而ThreadLocalMap能够存储以ThreadLocal为key的键值对。 好比咱们在同一个线程中声明了两个 ThreadLocal 对象的话，会使用 Thread内部都是使用仅有那个ThreadLocalMap 存放数据的，ThreadLocalMap的 key 就是 ThreadLocal对象，value 就是 ThreadLocal 对象调用set方法设置的值。ThreadLocal 是 map结构是为了让每一个线程能够关联多个 ThreadLocal变量。这也就解释了 ThreadLocal 声明的变量为何在每个线程都有本身的专属本地变量。

ThreadLocalMap是ThreadLocal的静态内部类。

3.4. ThreadLocal 内存泄露问题

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用,而 value 是强引用。因此，若是 ThreadLocal 没有被外部强引用的状况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来，ThreadLocalMap 中就会出现key为null的Entry。假如咱们不作任何措施的话，value 永远没法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种状况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal方法后 最好手动调用remove()方法

      static class Entry extends WeakReference<ThreadLocal<?>> {  /** The value associated with this ThreadLocal. */  Object value;   Entry(ThreadLocal<?> k, Object v) {  super(k);  value = v;  }  }

弱引用介绍：

若是一个对象只具备弱引用，那就相似于无关紧要的生活用品。弱引用与软引用的区别在于：只具备弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程当中，一旦发现了只具备弱引用的对象，无论当前内存空间足够与否，都会回收它的内存。不过，因为垃圾回收器是一个优先级很低的线程， 所以不必定会很快发现那些只具备弱引用的对象。

弱引用能够和一个引用队列（ReferenceQueue）联合使用，若是弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

4. 线程池

4.1. 为何要用线程池？

池化技术相比你们已经家常便饭了，线程池、数据库链接池、Http 链接池等等都是对这个思想的应用。池化技术的思想主要是为了减小每次获取资源的消耗，提升对资源的利用率。

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

这里借用《Java 并发编程的艺术》提到的来讲一下使用线程池的好处：

• 下降资源消耗。经过重复利用已建立的线程下降线程建立和销毁形成的消耗。
• 提升响应速度。当任务到达时，任务能够不须要的等到线程建立就能当即执行。
• 提升线程的可管理性。线程是稀缺资源，若是无限制的建立，不只会消耗系统资源，还会下降系统的稳定性，使用线程池能够进行统一的分配，调优和监控。

4.2. 实现Runnable接口和Callable接口的区别

Runnable自Java 1.0以来一直存在，但Callable仅在Java 1.5中引入,目的就是为了来处理Runnable不支持的用例。Runnable 接口不会返回结果或抛出检查异常，可是**Callable 接口**能够。因此，若是任务不须要返回结果或抛出异常推荐使用 Runnable 接口，这样代码看起来会更加简洁。

工具类 Executors 能够实现 Runnable 对象和 Callable 对象之间的相互转换。（Executors.callable（Runnable task）或 Executors.callable（Runnable task，Object resule））。

Runnable.java

@FunctionalInterface
public interface Runnable {  /**  * 被线程执行，没有返回值也没法抛出异常  */  public abstract void run(); }

Callable.java

@FunctionalInterface
public interface Callable<V> {  /**  * 计算结果，或在没法这样作时抛出异常。  * @return 计算得出的结果  * @throws 若是没法计算结果，则抛出异常  */  V call() throws Exception; }

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

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

咱们以**AbstractExecutorService**接口中的一个 submit 方法为例子来看看源代码：

    public Future<?> submit(Runnable task) {  if (task == null) throw new NullPointerException();  RunnableFuture<Void> ftask = newTaskFor(task, null);  execute(ftask);  return ftask;  }

上面方法调用的 newTaskFor 方法返回了一个 FutureTask 对象。

    protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {  return new FutureTask<T>(runnable, value);  }

咱们再来看看execute()方法：

    public void execute(Runnable command) {  ...  }

4.4. 如何建立线程池

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

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

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

方式一：经过构造方法实现  方式二：经过Executor 框架的工具类Executors来实现 咱们能够建立三种类型的ThreadPoolExecutor：

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

对应Executors工具类中的方法如图所示： 

4.5 ThreadPoolExecutor 类分析

ThreadPoolExecutor 类中提供的四个构造方法。咱们来看最长的那个，其他三个都是在这个构造方法的基础上产生（其余几个构造方法说白点都是给定某些默认参数的构造方法好比默认制定拒绝策略是什么），这里就不贴代码讲了，比较简单。

    /**  * 用给定的初始参数建立一个新的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.corePoolSize = corePoolSize;  this.maximumPoolSize = maximumPoolSize;  this.workQueue = workQueue;  this.keepAliveTime = unit.toNanos(keepAliveTime);  this.threadFactory = threadFactory;  this.handler = handler;  }

下面这些对建立 很是重要，在后面使用线程池的过程当中你必定会用到！因此，务必拿着小本本记清楚。

4.5.1 ThreadPoolExecutor构造函数重要参数分析

ThreadPoolExecutor 3 个最重要的参数：

• corePoolSize : 核心线程数线程数定义了最小能够同时运行的线程数量。
• maximumPoolSize : 当队列中存放的任务达到队列容量的时候，当前能够同时运行的线程数量变为最大线程数。
• workQueue: 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，若是达到的话，新任务就会被存放在队列中。

ThreadPoolExecutor其余常见参数:

1. keepAliveTime:当线程池中的线程数量大于 corePoolSize 的时候，若是这时没有新的任务提交，核心线程外的线程不会当即销毁，而是会等待，直到等待的时间超过了 keepAliveTime才会被回收销毁；
2. unit : keepAliveTime 参数的时间单位。
3. threadFactory :executor 建立新线程的时候会用到。
4. handler :饱和策略。关于饱和策略下面单独介绍一下。

4.5.2 ThreadPoolExecutor 饱和策略

ThreadPoolExecutor 饱和策略定义:

若是当前同时运行的线程数量达到最大线程数量而且队列也已经被放满了任时，ThreadPoolTaskExecutor 定义一些策略:

• ThreadPoolExecutor.AbortPolicy：抛出 RejectedExecutionException来拒绝新任务的处理。
• ThreadPoolExecutor.CallerRunsPolicy：调用执行本身的线程运行任务。您不会任务请求。可是这种策略会下降对于新任务提交速度，影响程序的总体性能。另外，这个策略喜欢增长队列容量。若是您的应用程序能够承受此延迟而且你不能任务丢弃任何一个任务请求的话，你能够选择这个策略。
• ThreadPoolExecutor.DiscardPolicy： 不处理新任务，直接丢弃掉。
• ThreadPoolExecutor.DiscardOldestPolicy： 此策略将丢弃最先的未处理的任务请求。

举个例子： Spring 经过 ThreadPoolTaskExecutor 或者咱们直接经过 ThreadPoolExecutor 的构造函数建立线程池的时候，当咱们不指定 RejectedExecutionHandler 饱和策略的话来配置线程池的时候默认使用的是 ThreadPoolExecutor.AbortPolicy。在默认状况下，ThreadPoolExecutor 将抛出 RejectedExecutionException 来拒绝新来的任务 ，这表明你将丢失对这个任务的处理。 对于可伸缩的应用程序，建议使用 ThreadPoolExecutor.CallerRunsPolicy。当最大池被填满时，此策略为咱们提供可伸缩队列。（这个直接查看 ThreadPoolExecutor 的构造函数源码就能够看出，比较简单的缘由，这里就不贴代码了）

4.6 一个简单的线程池Demo:Runnable+ThreadPoolExecutor

为了让你们更清楚上面的面试题中的一些概念，我写了一个简单的线程池 Demo。

首先建立一个 Runnable 接口的实现类（固然也能够是 Callable 接口，咱们上面也说了二者的区别。）

MyRunnable.java

import java.util.Date;  /**  * 这是一个简单的Runnable类，须要大约5秒钟来执行其任务。  * @author shuang.kou  */ public class MyRunnable implements Runnable {   private String command;   public MyRunnable(String s) {  this.command = s;  }   @Override  public void run() {  System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date());  processCommand();  System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date());  }   private void processCommand() {  try {  Thread.sleep(5000);  } catch (InterruptedException e) {  e.printStackTrace();  }  }   @Override  public String toString() {  return this.command;  } } 

编写测试程序，咱们这里以阿里巴巴推荐的使用 ThreadPoolExecutor 构造函数自定义参数的方式来建立线程池。

ThreadPoolExecutorDemo.java

import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit;  public class ThreadPoolExecutorDemo {   private static final int CORE_POOL_SIZE = 5;  private static final int MAX_POOL_SIZE = 10;  private static final int QUEUE_CAPACITY = 100;  private static final Long KEEP_ALIVE_TIME = 1L;  public static void main(String[] args) {   //使用阿里巴巴推荐的建立线程池的方式  //经过ThreadPoolExecutor构造函数自定义参数建立  ThreadPoolExecutor executor = new ThreadPoolExecutor(  CORE_POOL_SIZE,  MAX_POOL_SIZE,  KEEP_ALIVE_TIME,  TimeUnit.SECONDS,  new ArrayBlockingQueue<>(QUEUE_CAPACITY),  new ThreadPoolExecutor.CallerRunsPolicy());   for (int i = 0; i < 10; i++) {  //建立WorkerThread对象（WorkerThread类实现了Runnable 接口）  Runnable worker = new MyRunnable("" + i);  //执行Runnable  executor.execute(worker);  }  //终止线程池  executor.shutdown();  while (!executor.isTerminated()) {  }  System.out.println("Finished all threads");  } } 

能够看到咱们上面的代码指定了：

1. corePoolSize: 核心线程数为 5。
2. maximumPoolSize ：最大线程数 10
3. keepAliveTime : 等待时间为 1L。
4. unit: 等待时间的单位为 TimeUnit.SECONDS。
5. workQueue：任务队列为 ArrayBlockingQueue，而且容量为 100;
6. handler:饱和策略为 CallerRunsPolicy。

Output：

pool-1-thread-2 Start. Time = Tue Nov 12 20:59:44 CST 2019
pool-1-thread-5 Start. Time = Tue Nov 12 20:59:44 CST 2019 pool-1-thread-4 Start. Time = Tue Nov 12 20:59:44 CST 2019 pool-1-thread-1 Start. Time = Tue Nov 12 20:59:44 CST 2019 pool-1-thread-3 Start. Time = Tue Nov 12 20:59:44 CST 2019 pool-1-thread-5 End. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-3 End. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-2 End. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-4 End. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-1 End. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-2 Start. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-1 Start. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-4 Start. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-3 Start. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-5 Start. Time = Tue Nov 12 20:59:49 CST 2019 pool-1-thread-2 End. Time = Tue Nov 12 20:59:54 CST 2019 pool-1-thread-3 End. Time = Tue Nov 12 20:59:54 CST 2019 pool-1-thread-4 End. Time = Tue Nov 12 20:59:54 CST 2019 pool-1-thread-5 End. Time = Tue Nov 12 20:59:54 CST 2019 pool-1-thread-1 End. Time = Tue Nov 12 20:59:54 CST 2019 

4.7 线程池原理分析

承接 4.6 节，咱们经过代码输出结果能够看出：线程池每次会同时执行 5 个任务，这 5 个任务执行完以后，剩余的 5 个任务才会被执行。 你们能够先经过上面讲解的内容，分析一下究竟是咋回事？（本身独立思考一会）

如今，咱们就分析上面的输出内容来简单分析一下线程池原理。

**为了搞懂线程池的原理，咱们须要首先分析一下 execute方法。**在 4.6 节中的 Demo 中咱们使用 executor.execute(worker)来提交一个任务到线程池中去，这个方法很是重要，下面咱们来看看它的源码：

   // 存放线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount)  private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));   private static int workerCountOf(int c) {  return c & CAPACITY;  }   private final BlockingQueue<Runnable> workQueue;   public void execute(Runnable command) {  // 若是任务为null，则抛出异常。  if (command == null)  throw new NullPointerException();  // ctl 中保存的线程池当前的一些状态信息  int c = ctl.get();   // 下面会涉及到 3 步 操做  // 1.首先判断当前线程池中之行的任务数量是否小于 corePoolSize  // 若是小于的话，经过addWorker(command, true)新建一个线程，并将任务(command)添加到该线程中；而后，启动该线程从而执行任务。  if (workerCountOf(c) < corePoolSize) {  if (addWorker(command, true))  return;  c = ctl.get();  }  // 2.若是当前之行的任务数量大于等于 corePoolSize 的时候就会走到这里  // 经过 isRunning 方法判断线程池状态，线程池处于 RUNNING 状态才会被而且队列能够加入任务，该任务才会被加入进去  if (isRunning(c) && workQueue.offer(command)) {  int recheck = ctl.get();  // 再次获取线程池状态，若是线程池状态不是 RUNNING 状态就须要从任务队列中移除任务，并尝试判断线程是否所有执行完毕。同时执行拒绝策略。  if (!isRunning(recheck) && remove(command))  reject(command);  // 若是当前线程池为空就新建立一个线程并执行。  else if (workerCountOf(recheck) == 0)  addWorker(null, false);  }  //3. 经过addWorker(command, false)新建一个线程，并将任务(command)添加到该线程中；而后，启动该线程从而执行任务。  //若是addWorker(command, false)执行失败，则经过reject()执行相应的拒绝策略的内容。  else if (!addWorker(command, false))  reject(command);  }

经过下图能够更好的对上面这 3 步作一个展现，下图是我为了省事直接从网上找到，原地址不明。

如今，让咱们在回到 4.6 节咱们写的 Demo， 如今应该是否是很容易就能够搞懂它的原理了呢？

没搞懂的话，也不要紧，能够看看个人分析：

咱们在代码中模拟了 10 个任务，咱们配置的核心线程数为 5 、等待队列容量为 100 ，因此每次只可能存在 5 个任务同时执行，剩下的 5 个任务会被放到等待队列中去。当前的 5 个任务之行完成后，才会之行剩下的 5 个任务。

5. Atomic 原子类

5.1. 介绍一下Atomic 原子类

Atomic 翻译成中文是原子的意思。在化学上，咱们知道原子是构成通常物质的最小单位，在化学反应中是不可分割的。在咱们这里 Atomic 是指一个操做是不可中断的。即便是在多个线程一块儿执行的时候，一个操做一旦开始，就不会被其余线程干扰。

因此，所谓原子类说简单点就是具备原子/原子操做特征的类。

并发包 java.util.concurrent 的原子类都存放在java.util.concurrent.atomic下,以下图所示。

5.2. JUC 包中的原子类是哪4类?

基本类型

使用原子的方式更新基本类型

• AtomicInteger：整形原子类
• AtomicLong：长整型原子类
• AtomicBoolean：布尔型原子类

数组类型

使用原子的方式更新数组里的某个元素

• AtomicIntegerArray：整形数组原子类
• AtomicLongArray：长整形数组原子类
• AtomicReferenceArray：引用类型数组原子类

引用类型

• AtomicReference：引用类型原子类
• AtomicStampedReference：原子更新引用类型里的字段原子类
• AtomicMarkableReference ：原子更新带有标记位的引用类型

对象的属性修改类型

• AtomicIntegerFieldUpdater：原子更新整形字段的更新器
• AtomicLongFieldUpdater：原子更新长整形字段的更新器
• AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，能够解决使用 CAS 进行原子更新时可能出现的 ABA 问题。

5.3. 讲讲 AtomicInteger 的使用

AtomicInteger 类经常使用方法

public final int get() //获取当前的值 public final int getAndSet(int newValue)//获取当前的值，并设置新的值 public final int getAndIncrement()//获取当前的值，并自增 public final int getAndDecrement() //获取当前的值，并自减 public final int getAndAdd(int delta) //获取当前的值，并加上预期的值 boolean compareAndSet(int expect, int update) //若是输入的数值等于预期值，则以原子方式将该值设置为输入值（update） public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置以后可能致使其余线程在以后的一小段时间内仍是能够读到旧的值。

AtomicInteger 类的使用示例

使用 AtomicInteger 以后，不用对 increment() 方法加锁也能够保证线程安全。

class AtomicIntegerTest {  private AtomicInteger count = new AtomicInteger();  //使用AtomicInteger以后，不须要对该方法加锁，也能够实现线程安全。  public void increment() {  count.incrementAndGet();  }   public int getCount() {  return count.get();  } } 

5.4. 能不能给我简单介绍一下 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 能够保证任什么时候刻任何线程总能拿到该变量的最新值。

关于 Atomic 原子类这部分更多内容能够查看个人这篇文章：并发编程面试必备：JUC 中的 Atomic 原子类总结

6. AQS

6.1. AQS 介绍

AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。

AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用普遍的大量的同步器，好比咱们提到的ReentrantLock，Semaphore，其余的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。固然，咱们本身也能利用AQS很是轻松容易地构造出符合咱们本身需求的同步器。

6.2. AQS 原理分析

AQS 原理这部分参考了部分博客，在5.2节末尾放了连接。

在面试中被问到并发知识的时候，大多都会被问到“请你说一下本身对于AQS原理的理解”。下面给你们一个示例供你们参加，面试不是背题，你们必定要加入本身的思想，即便加入不了本身的思想也要保证本身可以通俗的讲出来而不是背出来。

下面大部份内容其实在AQS类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话能够看看源码。

6.2.1. AQS 原理概览

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

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

看个AQS(AbstractQueuedSynchronizer)原理图：

AQS使用一个int成员变量来表示同步状态，经过内置的FIFO队列来完成获取资源线程的排队工做。AQS使用CAS对该同步状态进行原子操做实现对其值的修改。

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

状态信息经过protected类型的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); }

6.2.2. AQS 对资源的共享方式

AQS定义两种资源共享方式

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

ReentrantReadWriteLock 能够当作是组合式，由于ReentrantReadWriteLock也就是读写锁容许多个线程同时对某一资源进行读。

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

6.2.3. AQS底层使用了模板方法模式

同步器的设计是基于模板方法模式的，若是须要自定义同步器通常的方式是这样（模板方法模式很经典的一个应用）：

1. 使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
2. 将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。

推荐两篇 AQS 原理和相关源码分析的文章：

• http://www.cnblogs.com/waterystone/p/4920797.html
• https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html

6.3. AQS 组件总结

• Semaphore(信号量)-容许多个线程同时访问： synchronized 和 ReentrantLock 都是一次只容许一个线程访问某个资源，Semaphore(信号量)能够指定多个线程同时访问某个资源。
• CountDownLatch （倒计时器）： CountDownLatch是一个同步工具类，用来协调多个线程之间的同步。这个工具一般用来控制线程等待，它可让某一个线程等待直到倒计时结束，再开始执行。
• CyclicBarrier(循环栅栏)： CyclicBarrier 和 CountDownLatch 很是相似，它也能够实现线程间的技术等待，可是它的功能比 CountDownLatch 更加复杂和强大。主要应用场景和 CountDownLatch 相似。CyclicBarrier 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要作的事情是，让一组线程到达一个屏障（也能够叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，全部被屏障拦截的线程才会继续干活。CyclicBarrier默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每一个线程调用await()方法告诉 CyclicBarrier 我已经到达了屏障，而后当前线程被阻塞。

7 Reference

• 《深刻理解 Java 虚拟机》
• 《实战 Java 高并发程序设计》
• 《Java并发编程的艺术》
• http://www.cnblogs.com/waterystone/p/4920797.html
• https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html
• https://www.journaldev.com/1076/java-threadlocal-example