Java面试准备之并发进阶一

说一说自己对于 synchronized 关键字的了解

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

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

说说自己是怎么使用 synchronized 关键字，在项目中用到了吗

synchronized 关键字最主要有以下 3 种应用方式，下面分别介绍

• 修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁
• 修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁
• 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

总结： synchronized 关键字加到静态方法和 synchronized(class)代码块上都是给 Class 类上锁。synchronized 关键字加到实例方法上是给对象实例上锁。尽量不要使用 synchronized(String a) 因为 JVM 中，字符串常量池具有缓存功能！

面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！”

双重校验锁实现对象单例（线程安全）

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 的指令重排，保证在多线程环境下也能正常运行。

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

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

Java 虚拟机中的同步(Synchronization)基于进入和退出管程(Monitor)对象实现， 无论是显式同步(有明确的 monitorenter 和 monitorexit 指令,即同步代码块)还是隐式同步都是如此。在 Java 语言中，同步用的最多的地方可能是被 synchronized 修饰的同步方法。同步方法并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的。

推荐阅读：深入理解Java并发之synchronized实现原理

1、synchronized 同步语句块的情况

public class SynchronizedDemo {

    public void method(){
        synchronized (this){
            System.out.println("synchronized code");
        }
    }
}

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

从上面我们可以看出：

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

2、synchronized 修饰方法的的情况

public class SynchronizedDemo {

    public synchronized void foo(){
        System.out.println("synchronized method");
    }
}

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

说说 JDK1.6 之后的synchronized 关键字底层做了哪些优化，可以详细介绍一下这些优化吗

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

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

推荐阅读：不可不说的Java“锁”事

谈谈 synchronized和ReentrantLock 的区别

1、两者都是可重入锁

两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。

2、synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API

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

3、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是一个不错的选择。

4、性能已不是选择标准

Java内存模型

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

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

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

推荐阅读：Java内存模型（JMM）总结

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

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

说一下Lock锁的底层原理

synchronized 依赖于 JVM 而 Lock 依赖于 API，我们研究 Lock 锁的底层原理，通过学习 Lock 锁的实现类 ReentrantLock 。

ReentrantLock 锁基于 AQS(AbstractQueuedSynchronizer)来实现的。 其中的 Node 节点通过双向链表（ 用于存储等待中的线程）进行存储，被 volatile 所修饰，int 类型的 state 变量来表示同步状态。获取锁时，AQS 使用 CAS 对该同步状态进行原子操作实现对其值的修改，如果当场没获取到，会将该线程放在线程等待链表中。释放锁时，修改状态值，调整等待链表。

推荐阅读：深入浅出Java锁--Lock实现原理(底层实现)

说说 synchronized 关键字和 Lock 类的区别

ThreadLocal 是什么？有哪些使用场景？

它是线程的局部变量，属于线程自身所有，不在多个线程间共享。ThreadLocal 定义的通常是与线程关联的私有静态字段（例如，用户ID或事务ID）。

1. 使用 ThreadLocal 可以代替一些参数的显式传递。
2. 比如用来存储用户 Session。Session 的特性很适合 ThreadLocal ，因为 Session 只在当前会话周期内有效，会话结束便销毁。
3. 在一些多线程的情况下，如果用线程同步的方式，当并发比较高的时候会影响性能，可以改为 ThreadLocal 的方式，例如高性能序列化框架 Kyro 就要用 ThreadLocal 来保证高性能和线程安全；
4. 线程内上下文管理器、数据库连接等可以用到 ThreadLocal;

ThreadLocal示例

import java.text.SimpleDateFormat;
import java.util.Random;

public class ThreadLocalDemo implements Runnable {

    // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
    private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMDD HHmm"));

    @Override
    public void run() {
        System.out.println("Thread Name = "+Thread.currentThread().getName()+" default form atter = "+formatter.get().toPattern());

        try {
            Thread.sleep(new Random().nextInt(1000));
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        formatter.set(new SimpleDateFormat());

        System.out.println("Thread Name = "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
    }

    public static void main(String[] args) throws InterruptedException {
        ThreadLocalDemo obj = new ThreadLocalDemo();
        for(int i=0;i<10;i++){
            Thread thread = new Thread(obj,""+i);
            Thread.sleep(new Random().nextInt(1000));
            thread.start();
        }
    }
}

执行结果为：

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

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

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的封装，传递了变量值。

每个 Thread 中都具备一个 ThreadLocalMap，而 ThreadLocalMap 可以存储以 ThreadLocal 为 key 的键值对。这里解释了为什么每个线程访问同一个 ThreadLocal，得到的确是不同的数值。另外，ThreadLocal 是 map 结构是为了让每个线程可以关联多个 ThreadLocal 变量。

ThreadLocalMap 是 ThreadLocal 的静态内部类。

ThreadLocal 内存泄露问题

实际上 ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用，而 value 是强引用。弱引用的特点是，如果这个对象只存在弱引用，那么在下一次垃圾回收的时候必然会被清理掉。

所以如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会被清理掉的，这样一来 ThreadLocalMap 中使用这个 ThreadLocal 的 key 也会被清理掉。但是，value 是强引用，不会被清理，这样一来就会出现 key 为 null 的 value，在线程对象结束前，会发生内存泄漏。（ 比如使用线程池的时候，线程结束是不会销毁的，会再次使用的就可能出现内存泄露 。 ）

ThreadLocalMap 实现中已经考虑了这种情况，在调用get()、 set()、remove() 方法的时候，会清理掉 key 为 null 的记录。如果说会出现内存泄漏，那只有在出现了 key 为 null 的记录后，没有手动调用 remove() 方法，并且之后也不再调用 get()、 set()、remove() 方法的情况下。

推荐阅读：深入浅出ThreadLocal

ThreadLocal内存泄漏问题

为什么要用线程池？

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

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

创建线程池有哪几种方式？

①. newFixedThreadPool(int nThreads)

创建一个固定长度的线程池，每当提交一个任务就创建一个线程，直到达到线程池的最大数量，这时线程规模将不再变化，当线程发生未预期的错误而结束时，线程池会补充一个新的线程。

②. newCachedThreadPool()

创建一个可缓存的线程池，如果线程池的规模超过了处理需求，将自动回收空闲线程，而当需求增加时，则可以自动添加新线程，线程池的大小依赖于操作系统。

③. newSingleThreadExecutor()

这是一个单线程的Executor，它创建单个工作线程来执行任务，如果这个线程异常结束，会创建一个新的来替代它；它的特点是能确保依照任务在队列中的顺序来串行执行。

④. newScheduledThreadPool(int corePoolSize)

创建了一个固定长度的线程池，而且以延迟或定时的方式来执行任务，类似于Timer。

public class ThreadPool {
    public static class HelloRunnable implements Runnable{
        @Override
        public void run() {
            String name = Thread.currentThread().getName();
            System.out.println(name+"----it's runnable");
        }
    }

    ExecutorService es = Executors.newCachedThreadPool();
    public void getThreadPool2(){
        for(int i=0;i<12;i++){
            HelloRunnable thread = new HelloRunnable();
            es.execute(thread);
        }
        es.shutdown();
    }

    ExecutorService es3 = Executors.newFixedThreadPool(2);
    public void getThreadPool3(){
        for(int i=0;i<12;i++) {
            HelloRunnable thread = new HelloRunnable();
            es3.execute(thread);
        }
        es3.shutdown();
    }

    ExecutorService es4 = Executors.newSingleThreadExecutor();
    public void getThreadPool4(){
        for(int i=0;i<12;i++) {
            HelloRunnable thread = new HelloRunnable();
            es4.execute(thread);
        }
        es4.shutdown();
    }

    ScheduledExecutorService es5 = Executors.newScheduledThreadPool(2);
    public void getThreadPool5(){
        HelloRunnable thread = new HelloRunnable();
        //参数1：目标对象   参数2：隔多长时间开始执行线程，    参数3：执行周期       参数4：时间单位
        es5.scheduleAtFixedRate(thread, 0, 100, TimeUnit.MICROSECONDS);
    }
}

线程池都有哪些状态？

线程池有 5 种状态：Running、ShutDown、Stop、Tidying、Terminated。

1.RUNNING：这是最正常的状态，接受新的任务，处理等待队列中的任务。线程池的初始化状态是 RUNNING。线程池被一旦被创建，就处于 RUNNING 状态，并且线程池中的任务数为0。

2.SHUTDOWN：不接受新的任务提交，但是会继续处理等待队列中的任务。调用线程池的 shutdown()方法时，线程池由 RUNNING -> SHUTDOWN。

3.STOP：不接受新的任务提交，不再处理等待队列中的任务，中断正在执行任务的线程。调用线程池的 shutdownNow()方法时，线程池由(RUNNING or SHUTDOWN ) -> STOP。

4.TIDYING：所有的任务都销毁了，workCount 为 0，线程池的状态在转换为 TIDYING 状态时，会执行钩子方法 terminated()。因为 terminated()在 ThreadPoolExecutor 类中是空的，所以用户想在线程池变为 TIDYING 时进行相应的处理；可以通过重载 terminated()函数来实现。

当线程池在 SHUTDOWN 状态下，阻塞队列为空并且线程池中执行的任务也为空时，就会由 SHUTDOWN -> TIDYING。

当线程池在 STOP 状态下，线程池中执行的任务为空时，就会由 STOP -> TIDYING。

5.TERMINATED：线程池处在 TIDYING 状态时，执行完 terminated()之后，就会由 TIDYING -> TERMINATED。

ThreadPoolExecutor七大参数

通过查看上述三大方法的源码，可以发现都是 new 了一个 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;
}

参数理解：

• corePoolSize：核心线程数。在创建了线程池后，线程中没有任何线程，等到有任务到来时才创建线程去执行任务。默认情况下，在创建了线程池后，线程池中的线程数为0，当有任务来之后，就会创建 一个线程去执行任务，当线程池中的线程数目达到corePoolSize后，就会把到达的任务放到缓存队列当中。
• maximumPoolSize：最大线程数。表明线程中最多能够创建的线程数量，此值必须大于等于1。
• keepAliveTime：空闲的线程保留的时间。
• unit：空闲线程的保留时间单位。
• BlockingQueue：阻塞队列，存储等待执行的任务。参数有ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue可选。
• ThreadFactory：线程工厂，用来创建线程，一般默认即可
• RejectedExecutionHandler：队列已满，而且任务量大于最大线程的异常处理策略。有以下取值

ThreadPoolExecutor.AbortPolicy  //丢弃任务并抛出RejectedExecutionException异常
ThreadPoolExecutor.CallerRunsPolicy //由调用线程处理该任务
ThreadPoolExecutor.DiscardOldestPolicy  //丢弃队列最前面的任务，然后重新尝试执行任务
ThreadPoolExecutor.DiscardPolicy    //也是丢弃任务，但是不抛出异常。

ThreadPoolExecutor底层原理

我们用个案例来进行解析：银行办理业务。比如说目前银行只有两个工作窗口对外开放，有三个空闲位置允许等待，当一下子来了5个人，其中两个人去办理业务，另外三个人去等待。如果人数大于5，则临时开放另外三个工作窗口来处理业务办理。那么该银行最多一次可以接收8个人，其中5个人办理业务，另外3个人等候。

流程图如下：

1. 在创建了线程池后，开始等待请求。

2. 当调用 execute()方法添加一个请求任务时，线程池会做出如下判断：

   1. 如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务：
   2. 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入队列：
   3. 如果这个时候队列满了且正在运行的线程数量还小于 maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务;
   4. 如果队列满了且正在运行的线程数量大 maximumPoolSize，那么线程池会启动饱和拒绝策略来执行。
3. 当一个线程完成任务时，它会从队列中取下一个任务来执行。

4. 当一个线程无事可做超过一定的时间(keepA1iveTime)时，线程会判断：

   • 如果当前运行的线程数大于 corePoolSize ，那么这个线程就被停掉。
   • 所以线程池的所有任务完成后，它最终会收缩到 corePoolSize 的大小。

代码实现为：

public class PoolDemo02 {

    static final int NUM = 8;
    public static void main(String[] args) {
        ExecutorService executorService = new ThreadPoolExecutor(2, 5, 3, TimeUnit.SECONDS, new LinkedBlockingDeque<>(3),
                Executors.defaultThreadFactory(),
                new ThreadPoolExecutor.AbortPolicy());//该拒绝策略会抛出异常信息

        try {
            //最大承载：Deque+max=3+5
            for (int i = 1; i <= NUM; i++) {
                executorService.execute(() -> {
                    System.out.println(Thread.currentThread().getName());
                });
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            executorService.shutdown();
        }
    }
}

当 NUM 值不大于5时，执行结果为：

pool-1-thread-2
pool-1-thread-1
pool-1-thread-2
pool-1-thread-1
pool-1-thread-2

当 NUM 值大于5，不大于8时，执行结果为：

pool-1-thread-1
pool-1-thread-2
pool-1-thread-1
pool-1-thread-2
pool-1-thread-3
pool-1-thread-1
pool-1-thread-4
pool-1-thread-5

当 NUM 值大于8时，执行会报错，错误信息如下：

java.util.concurrent.RejectedExecutionException

线程池中 submit()和 execute()方法有什么区别？

• 接收的参数列表不一样
• submit 有返回值，而 execute 没有
• submit 方便 Exception 处理

线程池相关问题

线程池被创建后里面有线程吗？如果没有的话，你知道有什么方法对线程池进行预热吗？

线程池被创建后如果没有任务过来，里面是不会有线程的。如果需要预热的话可以调用下面的两个方法：

全部启动：

仅启动一个：

核心线程数会被回收吗？需要什么设置？

核心线程数默认是不会被回收的，如果需要回收核心线程数，需要调用下面的方法：

allowCoreThreadTimeOut 该值默认为 false。

线程池提交方式

线程池的提交方式一共有四种：一种 execute，无返回值。三种 submit，有返回值。

submit 中按照提交任务的类型又分为两种：一个是 Callable，一个是 Runable。

submit 中 Runable 的任务类型又有两个重载方法：一个返回空，一个返回了个对象。

另外在这三种 submit 方法实现代码中可以看到，最终还是调用了同一个 execute 方法，如下图所示：

所以，“只有 execute 这一种提交方式”这一种说法也是没错的。

线程池中 submit()和 execute()方法有什么区别？

• 接收的参数列表不一样
• submit 有返回值，而 execute 没有
• submit 方便 Exception 处理

如下题所示，请问线程池中有多少个线程在运行？

ExecutorService executorService = new ThreadPoolExecutor(10, 30, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000),
        Executors.defaultThreadFactory(),
        new ThreadPoolExecutor.AbortPolicy());

假设这个时候来了 100 个比较耗时的任务，请问有多少个线程在运行？

首先这是 JDK 的线程池，核心线程数为10，阻塞队列为 1000，最大线程数为30。当任务来临时，线程池会做出如下判断：

1. 如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务：
2. 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入队列：
3. 如果这个时候队列满了且正在运行的线程数量还小于 maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务;
4. 如果队列满了且正在运行的线程数量大 maximumPoolSize，那么线程池会启动饱和拒绝策略来执行。

所以最终的答案是 10。

和 JDK 不同，Tomcat 和 Dubbo 目前是先把最大线程数用完，再让任务进入队列。

其实我们也可以先把最大线程数用完，然后再让任务进入队列。通过自定义队列，重写其 offer 方法就可以实现。目前我知道的 Tomcat 和 Dubbo 都提供了这样策略的线程池。

当线程池里面的线程出现异常时

经过 why 大的解读，该面试题不够严谨，需要重新描述一下： 一个线程池中的线程抛出了未经捕获的运行时异常，那么线程池会怎么处理这个线程？

那么如果线程池中线程捕获了异常，那么线程池该如何处理呢？

如果子线程捕获了异常，该异常不会被封装到 Future 里面。是通过 FutureTask 的 run 方法里面的 setException 和 set 方法实现的。在这两个方法里面完成了 FutureTask 里面的 outcome 变量的设置，同时完成了从 NEW 到 NORMAL 或者 EXCEPTIONAL 状态的流转。

推荐阅读：【原创】有的线程它死了，于是它变成一道面试题。

如果由于线程池满了，导致抛出拒绝异常呢？

如果线程池没有捕获异常，如下图所示：

JVM 会打印堆栈信息的日志，仅打印一次。

而当我们捕获了异常之后，改成这样：

线程池拒绝了几次，就会打印几次异常信息， 。

线程池异常处理关键是 dispatchUncaughtException 方法。 分为以下三种情况总结：

第一种：submit 方法提交一个会抛出运行时异常的任务，捕不捕获异常都可以。

第二种：execute 方法提交一个会抛出运行时异常的任务，不捕获异常。

第三种：submit 或者 execute 提交，让线程池饱和之后抛出拒绝异常，代码没有捕获异常。

第一种情况，无论如何都不会触发 dispatchUncaughtException 方法。因为 submit 方法提交，不论你捕获与否，源码里面都帮你捕获了。

第二种情况，如果不捕获异常，会触发 dispatchUncaughtException 方法，因为 runWorker 方法的源码里面虽然捕获了异常，但是又抛出去了，而我们自己没有捕获，所以会触发 dispatchUncaughtException 方法。

第三种情况，和第二种其实是一样的。没有捕获，就会触发。

实际应用中如何设置核心线程数？

分析下线程池处理的程序是CPU密集型还是IO密集型

CPU密集型：corePoolSize = CPU核数 + 1

IO密集型：corePoolSize = CPU核数 * 2

maxPoolSize 最大线程数在生产环境上我们往往设置成corePoolSize一样，这样可以减少在处理过程中创建线程的开销。

在 java 程序中怎么保证多线程的运行安全？

1. 原子性：提供互斥访问，同一时刻只能有一个线程对数据进行操作，（atomic,synchronized）；

2. 可见性：一个线程对主内存的修改可以及时地被其他线程看到，（synchronized,volatile）；

3. 有序性：一个线程观察其他线程中的指令执行顺序，由于指令重排序，该观察结果一般杂乱无序，（happens-before原则）。