java table修改指定行_JAVA面试（2）JUC

Hashmap与Concurrenthashmap原理（1.7和1.8的区别）

hashmap

1.7 数组+链表

1.8 数组+链表+红黑树

concurrenthashmap

1.7 数组+链表+分段锁，Segment数组，Segment是继承ReentrantLock的可重入锁，也就是说对于每个Segment的操作可以通过加锁解锁的方式来保证线程的安全性。对单个segment扩容。

1.8 数组+链表+红黑树，

利用 CAS+Synchronized 来保证并发更新的安全

1.8 的锁粒度是桶，相比于 1.7 的分段锁，锁粒度更小，并发度更高。

计算size

将所有 size 变化写入一个变量和一个数组。
计算 size 时，将变量和数组中的非空元素都加起来。

全程 CAS

只在数组未初始化且没有线程争用时，将 size 变化写入变量。
否则，只将 size 变化写入数组中任一元素。

数组可扩容，长度上限为机器核心数，长度也恒为 2 的幂。

线程探针哈希

思想：将 size 的变化分散到多个变量中，来降低线程冲突。

1.7 做法：两次不加锁将所有段的 size 加起来。两次结果不同，加锁后再加一遍。

put 操作

不允许 key 或 value 为 null。

如果桶为空，CAS 自旋为桶添加第一个结点。
桶不为空，

• 桶内第一个结点为 ForwardingNode，表示正在扩容，且当前桶已迁移完成，当前线程先去协助扩容，扩容完成后再执行 put 操作。
• 桶内第一个结点不是 ForwardingNode，则对桶内第一个结点加 Synchronized 锁。
  • 给 f 结点加锁后，还要判断 f 是否还为第一个结点，可能在加锁前，f 被 remove 操作移除。
  • 如果桶里是一颗红黑树，那么 f 是一个 TreeBin 对象，而不是红黑树的根结点。因为 put 会使根结点变化。所以对于红黑树锁住的是整个红黑树对象（TreeBin），而不是根结点（TreeNode）。
    • HashMap 里没有 TreeBin

1.8 的锁粒度为桶，我们要知道 CAS 和 Synchronized 在桶里的作用是什么。

get 操作

不阻塞

如果定位到 ForwardingNode，调用其 find 方法到 nextTable 中的对应桶中查找。

如果在桶迁移的过程中，碰到 get 操作呢？
在桶迁移过程中，会把结点复制一份再迁移（链表中 lastRun 及其后面的结点除外），不会改变原桶内链表或红黑树的链接关系。所以只要桶内放的不是 ForwardingNode 结点，都可以正常访问。

引用三张很好的图：
普通链表如何迁移？

红黑树如何迁移？

hash 桶迁移中以及迁移后如何处理存取请求？

remove 操作

也 Synchronized 桶内的第一个结点。

数组初始化：initTable 操作

CAS 自旋 + 双重 check
保证数组只被一个线程初始化，且只被初始化一次。

源码逻辑：将 sizeCtl CAS 为 -1 获取初始化权，初始化前再检查一遍数组是否初始化。

小小感悟：这种双重 check 在并发编程中很常见。最近的例子是 put、remove、transfer 等操作，还有一个常见的例子是单例模式的双检锁写法。

transfer 扩容操作

sizeCtl 字段
为负数时，表示数组正在初始化或扩容，-1 表示正在初始化，-(1+活跃扩容线程数) 表示正在扩容。
否则，当 table 为 null 时，非零表示数组的初始化长度，为 0 表示使用默认初始长度 16。当 table 非空后，表示扩容阈值。
补充：正在扩容时，sizeCtl 的高 16 位为 table 的长度标记，用于其他线程判断扩容是否结束。低 16 位才是 活跃扩容线程数+1。

每个线程负责迁移的桶的数量与机器的 CPU 核心数有关，至少负责 16 个桶的迁移。

transferIndex

分段迁移，每个线程负责迁移一段连续的桶。

正在迁移时，Synchronized 锁住桶中第一个结点。

每个线程负责的段是等长的。
起始位置为 i = transferIndex-1;
终止位置为 bound = transferIndex-stride;
从右向左迁移 --i >= bound

桶迁移完成后，在桶中放入 ForwardingNode 结点。
最后一个扩容线程负责切换数组 nextTable = null; table = nextTab;

引图，多线程迁移：

谈谈对Volatile的理解

Volatile在日常的单线程环境是应用不到的。Volatile修饰共享变量

Volatile是Java虚拟机提供的轻量级的同步机制（三大特性）

保证可见性

一个线程修改了volatile修饰的变量，当修改写回主内存时，另外一个线程立即看到最新的值。

为什么这里主线程中某个值被更改后，其它线程能马上知晓呢？

其实这里是用到了总线嗅探技术

多个处理器运算任务都涉及到同一块主内存区域的时候，将可能导致各自的缓存数据不一。

为了解决缓存一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议进行操作，这类协议主要有MSI、MESI等等。

MESI

当CPU写数据时，如果发现操作的变量是共享变量，即在其它CPU中也存在该变量的副本，会发出信号通知其它CPU将该内存变量的缓存行设置为无效，因此当其它CPU读取这个变量的时，发现自己缓存该变量的缓存行是无效的，那么它就会从内存中重新读取。

这里是用到了总线嗅探技术，就是每个处理器通过嗅探在总线上传播的数据来检查自己缓存值是否过期了，当处理器发现自己的缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置为无效状态，当处理器对这个数据进行修改操作的时候，会重新从内存中把数据读取到处理器缓存中。

为什么出现数值丢失？

各自线程在写入主内存的时候，出现了数据的丢失，而引起的数值缺失的问题

在多线程环境下 number ++ 在多线程环境下是非线程安全的，解决的方法有哪些呢？

• 在方法上加入 synchronized（重量级的同步机制）
• JUC下面的原子包装类，AtomicInteger来代替

AtomicInteger为什么能保证线程安全？

CAS底层原理

不保证原子性

就是一次操作，要么完全成功，要么完全失败。

假设现在有N个线程对同一个变量进行累加也是没办法保证结果是对的，因为读写这个过程并不是原子性的。

要解决也简单，要么用原子类，比如AtomicInteger，要么加锁(记得关注Atomic的底层)。

禁止指令重排

那Volatile是怎么保证不会被执行重排序的呢？

为了提高性能，编译器和处理器常常会对既定的代码执行顺序进行指令重排序。

volatile写是在前面和后面分别插入内存屏障（是一个CPU指令），而volatile读操作是在后面插入两个内存屏障。

写

读

volatile与synchronized的区别？

volatile只能修饰实例变量和类变量，而synchronized可以修饰方法，以及代码块。

volatile保证数据的可见性，但是不保证原子性(多线程进行写操作，不保证线程安全);而synchronized是一种排他(互斥)的机制。

volatile用于禁止指令重排序：可以解决单例双重检查对象初始化代码执行乱序问题。

volatile可以看做是轻量版的synchronized，volatile不保证原子性，但是如果是对一个共享变量进行多个线程的赋值，而没有其他的操作，那么就可以用volatile来代替synchronized，因为赋值本身是有原子性的，而volatile又保证了可见性，所以就可以保证线程安全了。

volatile属性的读写操作都是无锁的，它不能替代synchronized，因为它没有提供原子性和互斥性。因为无锁，不需要花费时间在获取锁和释放锁上，所以说它是低成本的。

Volatile的应用

单例模式代码

public class Singleton{
    private static Singleton singleton;
    private Singleton(){}
    public static synchronized Singleton getInstance(){
         if(singleton == null){
              singleton = new Singleton();
         }
         return singleton;
    }
}

通过引入Synchronized关键字，能够解决高并发环境下的单例模式问题

但是synchronized属于重量级的同步机制，它只允许一个线程同时访问获取实例的方法，但是为了保证数据一致性，而减低了并发性，因此采用的比较少.

public class Singleton{
     private static volatile Singleton singleton = null;
     public Singleton(){}
     public static Singleton getInstance(){
         if(singleton == null){
             synchronized(Singleton.class){
                if(singleton == null){
                   singleton = new Singleton();
                }
             }
         }
         return singleton;
     }

  public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                SingletonDemo.getInstance();
            }, String.valueOf(i)).start();
        }
    }
}

引入volatile，来保证出现指令重排的问题，从而保证单例模式的线程安全性

CAS底层原理

比较并交换：compareAndSet

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

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

这个就类似于SVN或者Git的版本号，如果没有人更改过，就能够正常提交，否者需要先将代码pull下来，合并代码后，然后提交

首先我们先看看 atomicInteger.getAndIncrement()方法的源码

从这里能够看到，底层又调用了一个unsafe类的getAndAddInt方法

1、unsafe类

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

注意Unsafe类的所有方法都是native修饰的，也就是说unsafe类中的方法都直接调用操作系统底层资源执行相应的任务

为什么Atomic修饰的包装类，能够保证原子性，依靠的就是底层的unsafe类

2、变量valueOffset

表示该变量值在内存中的偏移地址，因为Unsafe就是根据内存偏移地址获取数据的。

通过valueOffset，直接通过内存地址，获取到值，然后进行加1的操作

3、变量value用volatile修饰

保证了多线程之间的内存可见性

var5：就是我们从主内存中拷贝到工作内存中的值

那么操作的时候，需要比较工作内存中的值，和主内存中的值进行比较

假设执行 compareAndSwapInt返回false，那么就一直执行 while方法，直到期望的值和真实值一样

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

这里没有用synchronized，而用CAS，这样提高了并发性，也能够实现一致性，是因为每个线程进来后，进入的do while循环，然后不断的获取内存中的值，判断是否为最新，然后在进行更新操作。

假设线程A和线程B同时执行getAndInt操作（分别跑在不同的CPU上）

1. AtomicInteger里面的value原始值为3，即主内存中AtomicInteger的 value 为3，根据JMM模型，线程A和线程B各自持有一份价值为3的副本，分别存储在各自的工作内存
2. 线程A通过getIntVolatile(var1 , var2) 拿到value值3，这是线程A被挂起（该线程失去CPU执行权）
3. 线程B也通过getIntVolatile(var1, var2)方法获取到value值也是3，此时刚好线程B没有被挂起，并执行了compareAndSwapInt方法，比较内存的值也是3，成功修改内存值为4，线程B打完收工，一切OK
4. 这是线程A恢复，执行CAS方法，比较发现自己手里的数字3和主内存中的数字4不一致，说明该值已经被其它线程抢先一步修改过了，那么A线程本次修改失败，只能够重新读取后在来一遍了，也就是在执行do while
5. 线程A重新获取value值，因为变量value被volatile修饰，所以其它线程对它的修改，线程A总能够看到，线程A继续执行compareAndSwapInt进行比较替换，直到成功。

Unsafe类 + CAS思想： 也就是自旋，自我旋转

CAS缺点

CAS不加锁，保证一次性，但是需要多次比较

• 循环时间长，开销大（因为执行的是do while，如果比较不成功一直在循环，最差的情况，就是某个线程一直取到的值和预期值都不一样，这样就会无限循环）
• 只能保证一个共享变量的原子操作
  • 当对一个共享变量执行操作时，我们可以通过循环CAS的方式来保证原子操作
  • 但是对于多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候只能用锁来保证原子性
• 引出来ABA问题？

ABA问题

2个线程同时对同一个值(初始值为A)进行CAS操作，这三个线程如下

1. 线程1，期望值为A，欲更新的值为B
2. 线程2，期望值为A，欲更新的值为B

线程1抢先获得CPU时间片，而线程2因为其他原因阻塞了，线程1取值与期望的A值比较，发现相等然后将值更新为B，然后这个时候出现了线程3，期望值为B，欲更新的值为A，线程3取值与期望的值B比较，发现相等则将值更新为A，此时线程2从阻塞中恢复，并且获得了CPU时间片，这时候线程2取值与期望的值A比较，发现相等则将值更新为B，虽然线程2也完成了操作，但是线程2并不知道值已经经过了A->B->A的变化过程。

ABA问题带来的危害：

小明在提款机，提取了50元，因为提款机问题，有两个线程，同时把余额从100变为50

线程1（提款机）：获取当前值100，期望更新为50，

线程2（提款机）：获取当前值100，期望更新为50，

线程1成功执行，线程2某种原因block了，这时，某人给小明汇款50

线程3（默认）：获取当前值50，期望更新为100，

这时候线程3成功执行，余额变为100，

线程2从Block中恢复，获取到的也是100，compare之后，继续更新余额为50！！！

此时可以看到，实际余额应该为100（100-50+50），但是实际上变为了50（100-50+50-50）这就是ABA问题带来的成功提交。

解决方案：就是添加一个标记（版本号）来记录更改，两者的区别如下：

1：AtomicMarkableReference 利用一个boolean类型的标记来记录，只能记录它改变过，不能记录改变的次数
2：AtomicStampedReference 利用一个int类型的标记来记录，它能够记录改变的次数。

总结

CAS

CAS是compareAndSwap，比较当前工作内存中的值和主物理内存中的值，如果相同则执行规定操作，否者继续比较直到主内存和工作内存的值一致为止

CAS应用

CAS有3个操作数，内存值V，旧的预期值A，要修改的更新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否者什么都不做

synchronized 和 lock 有什么区别？用新的lock有什么好处？举例说明

1）synchronized属于JVM层面，属于java的关键字

• ​monitorenter（底层是通过monitor对象来完成，其实wait/notify等方法也依赖于monitor对象 只能在同步块或者方法中才能调用 wait/ notify等方法）
• Lock是具体类（java.util.concurrent.locks.Lock）是api层面的锁

2）使用方法：

• synchronized：不需要用户去手动释放锁，当synchronized代码执行后，系统会自动让线程释放对锁的占用
• ReentrantLock（重入锁）：则需要用户去手动释放锁，若没有主动释放锁，就有可能出现死锁的现象，需要lock() 和 unlock() 配置try catch语句来完成

3）等待是否中断

• synchronized：不可中断，除非抛出异常或者正常运行完成
• ReentrantLock：可中断，可以设置超时方法
  • 设置超时方法，trylock(long timeout, TimeUnit unit)
  • lockInterrupible() 放代码块中，调用interrupt() 方法可以中断

4）加锁是否公平

• synchronized：非公平锁
• ReentrantLock：默认非公平锁，构造函数可以传递boolean值，true为公平锁，false为非公平锁

5）锁绑定多个条件Condition

• synchronized：没有，要么随机，要么全部唤醒
• ReentrantLock：用来实现分组唤醒需要唤醒的线程，可以精确唤醒

JAVA的锁

独占锁（写锁） / 共享锁（读锁） / 互斥锁

独占锁：指该锁一次只能被一个线程所持有。对ReentrantLock和Synchronized而言都是独占锁

共享锁：指该锁可以被多个线程锁持有

对 ReentrantReadWriteLock 其 读锁 是 共享，其 写锁 是 独占

写的时候只能一个人写，但是读的时候，可以多个人同时读

原来我们使用ReentrantLock创建锁的时候，是独占锁，也就是说一次只能一个线程访问，但是有一个读写分离场景，读的时候想同时进行，因此原来独占锁的并发性就没这么好了，因为读锁并不会造成数据不一致的问题，因此可以多个人共享读

多个线程 同时读一个资源类没有任何问题，所以为了满足并发量，读取共享资源应该可以同时进行，但是如果一个线程想去写共享资源，就不应该再有其它线程可以对该资源进行读或写

读-读：能共存

读-写：不能共存

写-写：不能共存

可重入锁和递归锁ReentrantLock

可重入锁就是递归锁

指的是同一线程外层函数获得锁之后，内层递归函数仍然能获取到该锁的代码，在同一线程在外层方法获取锁的时候，在进入内层方法会自动获取锁

也就是说：线程可以进入任何一个它已经拥有的锁所同步的代码块

ReentrantLock / Synchronized 就是一个典型的可重入锁

代码

可重入锁就是，在一个method1方法中加入一把锁，方法2也加锁了，那么他们拥有的是同一把锁

public synchronized void method1() {
	method2();
}

public synchronized void method2() {

}

也就是说我们只需要进入method1后，那么它也能直接进入method2方法，因为他们所拥有的锁，是同一把。

作用

可重入锁的最大作用就是避免死锁。

Java锁之自旋锁

自旋锁：spinlock，是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU

原来提到的比较并交换（CAS），底层使用的就是自旋，自旋就是多次尝试，多次访问，不会阻塞的状态就是自旋。

优缺点

优点：循环比较获取直到成功为止，没有类似于wait的阻塞

缺点：当不断自旋的线程越来越多的时候，会因为执行while循环不断的消耗CPU资源

Java锁之公平锁和非公平锁

公平锁：是指多个线程按照申请锁的顺序来获取锁，类似于排队买饭，先来后到，先来先服务，就是公平的，也就是队列

非公平锁：是指多个线程获取锁的顺序，并不是按照申请锁的顺序，有可能申请的线程比先申请的线程优先获取锁，在高并发环境下，有可能造成优先级翻转，或者饥饿的线程（也就是某个线程一直得不到锁）

如何创建

并发包中ReentrantLock的创建可以指定析构函数的boolean类型来得到公平锁或者非公平锁，默认是非公平锁

/**
* 创建一个可重入锁，true 表示公平锁，false 表示非公平锁。默认非公平锁
*/
Lock lock = new ReentrantLock(true);

两者区别

公平锁：就是很公平，在并发环境中，每个线程在获取锁时会先查看此锁维护的等待队列，如果为空，或者当前线程是等待队列中的第一个，就占用锁，否者就会加入到等待队列中，以后安装FIFO的规则从队列中取到自己

非公平锁： 非公平锁比较粗鲁，上来就直接尝试占有锁，如果尝试失败，就再采用类似公平锁那种方式。

题外话

Java ReenttrantLock通过构造函数指定该锁是否公平，默认是非公平锁，因为非公平锁的优点在于吞吐量比公平锁大，对于synchronized而言，也是一种非公平锁

为什么Synchronized无法禁止指令重排，却能保证有序性

前言

首先我们要分析下这道题，这简单的一个问题，其实里面还是包含了很多信息的，要想回答好这个问题，面试者至少要知道一下概念：

• Java内存模型
• 并发编程有序性问题
• 指令重排
• synchronized锁
• 可重入锁
• 排它锁
• as-if-serial语义
• 单线程&多线程

标准解答

为了进一步提升计算机各方面能力，在硬件层面做了很多优化，如处理器优化和指令重排等，但是这些技术的引入就会导致有序性问题。

先解释什么是有序性问题，也知道是什么原因导致的有序性问题

我们也知道，最好的解决有序性问题的办法，就是禁止处理器优化和指令重排，就像volatile中使用内存屏障一样。

表明你知道啥是指令重排，也知道他的实现原理

但是，虽然很多硬件都会为了优化做一些重排，但是在Java中，不管怎么排序，都不能影响单线程程序的执行结果。这就是as-if-serial语义，所有硬件优化的前提都是必须遵守as-if-serial语义。

as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial语义使单线程程序员无需担心重排序会 干扰他们，也无需担心内存可见性问题。

重点！解释下什么是as-if-serial语义，因为这是这道题的第一个关键词，答上来就对了一半了

再说下synchronized，他是Java提供的锁，可以通过他对Java中的对象加锁，并且他是一种排他的、可重入的锁。

所以，当某个线程执行到一段被synchronized修饰的代码之前，会先进行加锁，执行完之后再进行解锁。在加锁之后，解锁之前，其他线程是无法再次获得锁的，只有这条加锁线程可以重复获得该锁。

介绍synchronized的原理，这是本题的第二个关键点，到这里基本就可以拿满分了。

synchronized通过排他锁的方式就保证了同一时间内，被synchronized修饰的代码是单线程执行的。所以呢，这就满足了as-if-serial语义的一个关键前提，那就是单线程，因为有as-if-serial语义保证，单线程的有序性就天然存在了。

死锁编码及定位分析(进程锁/线程锁)

死锁是指两个或多个以上的进程在执行过程中，因争夺资源而造成一种互相等待的现象，若无外力干涉那他们都将无法推进下去。如果资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。

产生死锁的原因

• 系统资源不足
• 进程运行推进的顺序不对
• 资源分配不当

死锁产生的四个必要条件

互斥

• • 解决方法：把互斥的共享资源封装成可同时访问

占有且等待

• • 解决方法：进程请求资源时，要求它不占有任何其它资源，也就是它必须一次性申请到所有的资源，这种方式会导致资源效率低。

非抢占式

• • 解决方法：如果进程不能立即分配资源，要求它不占有任何其他资源，也就是只能够同时获得所有需要资源时，才执行分配操作

循环等待

• • 解决方法：对资源进行排序，要求进程按顺序请求资源。

乐观锁和悲观锁

乐观锁：顾名思义，就是十分乐观，它总是认为不会出现问题，无论干什么都不去上锁~，如果出现了问题，再次更新值测试，这里使用了version字段。

也就是每次更新的时候同时维护一个version字段

乐观锁实现方式

• 取出记录时，获取当前的version
• 更新时，带上这个version
• 执行更新时，set version = newVersion where version = oldVersion
• 如果version不对，就更新失败

乐观锁：1：先查询，获得版本号 version =1

-- A 线程
update user set name = "麦冬", version = version + 1 
where id = 2 and version = 1

-- B 线程抢先完成，这个时候Version = 2，导致A修改失败
update user set name = "麦冬", version = version + 1 
where id = 2 and version = 1

MybatisPlus使用乐观锁

（国人团队苞米豆在Mybatis的基础上开发的框架，在Mybatis基础上扩展了许多功能）

首先需要在数据库增加version字典，默认为1

然后在实体类增加对应的字段

// 乐观锁Version注解
@Version
private Integer version;

注册组件，在MybatisPlusConfig中配置

// 注册乐观锁
@Bean
public OptimisticLockerInterceptor optimisticLockerInterceptor() {
	return new OptimisticLockerInterceptor();
}

悲观锁

顾名思义，就是十分悲观，它总是认为什么时候都会出现问题，无论什么操作都会上锁，再次操作

线程池（Java中有哪些方法获取多线程）

前言

获取多线程的方法，我们都知道有三种，还有一种是线程池

• 实现Runnable接口
• 实现Callable接口
• 实例化Thread类
• 使用线程池获取

Runnable接口

/**
 * 实现Runnable接口
 */
class MyThread implements Runnable {

    @Override
    public void run() {

    }
}

我们知道，实现Runnable接口的时候，需要重写run方法，也就是线程在启动的时候，会自动调用的方法

Callable接口

也需要实现call方法，但是这个时候我们还需要有返回值，这个Callable接口的应用场景一般就在于批处理业务，比如转账的时候，需要给一会返回结果的状态码回来，代表本次操作成功还是失败

/**
 * Callable有返回值
 * 批量处理的时候，需要带返回值的接口（例如支付失败的时候，需要返回错误状态）
 *
 */
class MyThread2 implements Callable<Integer> {

    @Override
    public Integer call() throws Exception {
        System.out.println("come in Callable");
        return 1024;
    }
}

最后我们需要做的就是通过Thread线程， 将MyThread2实现Callable接口的类包装起来

这里需要用到的是FutureTask类，他实现了Runnable接口，并且还需要传递一个实现Callable接口的类作为构造函数

// FutureTask：实现了Runnable接口，构造函数又需要传入 Callable接口
// 这里通过了FutureTask接触了Callable接口
FutureTask<Integer> futureTask = new FutureTask<>(new MyThread2());

然后在用Thread进行实例化，传入实现Runnabnle接口的FutureTask的类

Thread t1 = new Thread(futureTask, "aaa");
t1.start();

最后通过 utureTask.get() 获取到返回值

// 输出FutureTask的返回值
System.out.println("result FutureTask " + futureTask.get());

这就相当于原来我们的方式是main方法一条龙之心，后面在引入Callable后，对于执行比较久的线程，可以单独新开一个线程进行执行，最后在进行汇总输出

最后需要注意的是 要求获得Callable线程的计算结果，如果没有计算完成就要去强求，会导致阻塞，直到计算完成

也就是说 futureTask.get() 需要放在最后执行，这样不会导致主线程阻塞

也可以使用下面算法，使用类似于自旋锁的方式来进行判断是否运行完毕

// 判断futureTask是否计算完成
while(!futureTask.isDone()) {

}

多个线程执行 一个FutureTask的时候，只会计算一次

FutureTask<Integer> futureTask = new FutureTask<>(new MyThread2());

// 开启两个线程计算futureTask
new Thread(futureTask, "AAA").start();
new Thread(futureTask, "BBB").start();

如果我们要两个线程同时计算任务的话，那么需要这样写，需要定义两个futureTask

FutureTask<Integer> futureTask = new FutureTask<>(new MyThread2());
FutureTask<Integer> futureTask2 = new FutureTask<>(new MyThread2());

// 开启两个线程计算futureTask
new Thread(futureTask, "AAA").start();

new Thread(futureTask2, "BBB").start();

为什么用线程池ThreadPoolExecutor？

线程池做的主要工作就是控制运行的线程的数量，处理过程中，将任务放入到队列中，然后线程创建后，启动这些任务，如果线程数量超过了最大数量的线程排队等候，等其它线程执行完毕，再从队列中取出任务来执行。

它的主要特点为：线程复用、控制最大并发数、管理线程

线程池中的任务是放入到阻塞队列中的

线程池的好处

多核处理的好处是：省略的上下文的切换开销

原来我们实例化对象的时候，是使用 new关键字进行创建，到了Spring后，我们学了IOC依赖注入，发现Spring帮我们将对象已经加载到了Spring容器中，只需要通过@Autowrite注解，就能够自动注入，从而使用

因此使用多线程有下列的好处

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

架构说明

Java中线程池是通过Executor框架实现的，该框架中用到了Executor，Executors（代表工具类），ExecutorService，ThreadPoolExecutor这几个类。

创建线程池

Executors.newFixedThreadPool(int i) ：创建一个拥有 i 个线程的线程池

• • 执行长期的任务，性能好很多
  • 创建一个定长线程池，可控制线程数最大并发数，超出的线程会在队列中等待

Executors.newSingleThreadExecutor：创建一个只有1个线程的 单线程池

• • 一个任务一个任务执行的场景
  • 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序执行

Executors.newCacheThreadPool(); 创建一个可扩容的线程池

• • 执行很多短期异步的小程序或者负载教轻的服务器
  • 创建一个可缓存线程池，如果线程长度超过处理需要，可灵活回收空闲线程，如无可回收，则新建新线程

具体使用，首先我们需要使用Executors工具类，进行创建线程池，这里创建了一个拥有5个线程的线程池

// 一池5个处理线程（用池化技术，一定要记得关闭）
ExecutorService threadPool = Executors.newFixedThreadPool(5);

// 创建一个只有一个线程的线程池
ExecutorService threadPool = Executors.newSingleThreadExecutor();

// 创建一个拥有N个线程的线程池，根据调度创建合适的线程
ExecutorService threadPool = Executors.newCacheThreadPool();

然后我们执行下面的的应用场景

模拟10个用户来办理业务，每个用户就是一个来自外部请求线程

我们需要使用 threadPool.execute执行业务，execute需要传入一个实现了Runnable接口的线程

threadPool.execute(() -> {
	System.out.println(Thread.currentThread().getName() + "t 给用户办理业务");
});

然后我们使用完毕后关闭线程池

threadPool.shutdown();

完整代码为：

/**
 * 第四种获取 / 使用 Java多线程的方式，通过线程池
 * @author: 麦冬
 * @create: 2020-08-31-20:52
 */
public class MyThreadPoolDemo {
    public static void main(String[] args) {

        // Array  Arrays(辅助工具类)
        // Collection Collections(辅助工具类)
        // Executor Executors(辅助工具类)


        // 一池5个处理线程（用池化技术，一定要记得关闭）
        ExecutorService threadPool = Executors.newFixedThreadPool(5);

        // 模拟10个用户来办理业务，每个用户就是一个来自外部请求线程
        try {

            // 循环十次，模拟业务办理，让5个线程处理这10个请求
            for (int i = 0; i < 10; i++) {
                final int tempInt = i;
                threadPool.execute(() -> {
                    System.out.println(Thread.currentThread().getName() + "t 给用户:" + tempInt + " 办理业务");
                });
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            threadPool.shutdown();
        }

    }
}

最后结果：

pool-1-thread-1	 给用户:0 办理业务
pool-1-thread-5	 给用户:4 办理业务
pool-1-thread-1	 给用户:5 办理业务
pool-1-thread-4	 给用户:3 办理业务
pool-1-thread-2	 给用户:1 办理业务
pool-1-thread-3	 给用户:2 办理业务
pool-1-thread-2	 给用户:9 办理业务
pool-1-thread-4	 给用户:8 办理业务
pool-1-thread-1	 给用户:7 办理业务
pool-1-thread-5	 给用户:6 办理业务

我们能够看到，一共有5个线程，在给10个用户办理业务

底层实现

我们通过查看源码，点击了Executors.newSingleThreadExecutor 和 Executors.newFixedThreadPool能够发现底层都是使用了ThreadPoolExecutor

我们可以看到线程池的内部，还使用到了LinkedBlockingQueue 链表阻塞队列

同时在查看Executors.newCacheThreadPool 看到底层用的是 SynchronousBlockingQueue阻塞队列

最后查看一下，完整的三个创建线程的方法

线程池的重要参数

线程池在创建的时候，一共有7大参数

corePoolSize：核心线程数，线程池中的常驻核心线程数

• • 在创建线程池后，当有请求任务来之后，就会安排池中的线程去执行请求任务，近似理解为今日当值线程
  • 当线程池中的线程数目达到corePoolSize后，就会把到达的队列放到缓存队列中

maximumPoolSize：线程池能够容纳同时执行的最大线程数，此值必须大于等于1、

• • 相当有扩容后的线程数，这个线程池能容纳的最多线程数

keepAliveTime：多余的空闲线程存活时间

• • 当线程池数量超过corePoolSize时，当空闲时间达到keepAliveTime值时，多余的空闲线程会被销毁，直到只剩下corePoolSize个线程为止
  • 默认情况下，只有当线程池中的线程数大于corePoolSize时，keepAliveTime才会起作用

unit：keepAliveTime的单位 workQueue：任务队列，被提交的但未被执行的任务（类似于银行里面的候客区）

• • LinkedBlockingQueue：链表阻塞队列
  • SynchronousBlockingQueue：同步阻塞队列

threadFactory：表示生成线程池中工作线程的线程工厂，用于创建线程池 一般用默认即可 handler：拒绝策略，表示当队列满了并且工作线程大于线程池的最大线程数（maximumPoolSize3）时，如何来拒绝请求执行的Runnable的策略

当营业窗口和阻塞队列中都满了时候，就需要设置拒绝策略

拒绝策略

以下所有拒绝策略都实现了RejectedExecutionHandler接口

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

线程池底层工作原理

线程池运行架构图

文字说明

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

以顾客去银行办理业务为例，谈谈线程池的底层工作原理

1. 最开始假设来了两个顾客，因为corePoolSize为2，因此这两个顾客直接能够去窗口办理
2. 后面又来了三个顾客，因为corePool已经被顾客占用了，因此只有去候客区，也就是阻塞队列中等待
3. 后面的人又陆陆续续来了，候客区可能不够用了，因此需要申请增加处理请求的窗口，这里的窗口指的是线程池中的线程数，以此来解决线程不够用的问题
4. 假设受理窗口已经达到最大数，并且请求数还是不断递增，此时候客区和线程池都已经满了，为了防止大量请求冲垮线程池，已经需要开启拒绝策略
5. 临时增加的线程会因为超过了最大存活时间，就会销毁，最后从最大数削减到核心数

为什么不用默认创建的线程池？

线程池创建的方法有：固定数的，单一的，可变的，那么在实际开发中，应该使用哪个？

我们一个都不用，在生产环境中是使用自己自定义的

为什么不用Executors中JDK提供的？

根据阿里巴巴手册：并发控制这章

• 线程资源必须通过线程池提供，不允许在应用中自行显式创建线程
  • 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题，如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题
• 线程池不允许使用Executors去创建，而是通过ThreadToolExecutors的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
  • Executors返回的线程池对象弊端如下：
    • FixedThreadPool和SingleThreadPool：
      • 运行的请求队列长度为：Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM
    • CacheThreadPool和ScheduledThreadPool
      • 运行的请求队列长度为：Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM

手写线程池

采用默认拒绝策略

采用CallerRunsPolicy拒绝策略

采用DiscardOldestPolicy拒绝策略

线程池的合理参数

生产环境中如何配置 corePoolSize 和 maximumPoolSize

这个是根据具体业务来配置的，分为CPU密集型和IO密集型

CPU密集型

CPU密集的意思是该任务需要大量的运算，而没有阻塞，CPU一直全速运行

CPU密集任务只有在真正的多核CPU上才可能得到加速（通过多线程）

而在单核CPU上，无论你开几个模拟的多线程该任务都不可能得到加速，因为CPU总的运算能力就那些

CPU密集型任务配置尽可能少的线程数量：

一般公式：CPU核数 + 1个线程数

IO密集型

由于IO密集型任务线程并不是一直在执行任务，则可能多的线程，如 CPU核数 * 2

IO密集型，即该任务需要大量的IO操作，即大量的阻塞

在单线程上运行IO密集型的任务会导致浪费大量的CPU运算能力花费在等待上

所以IO密集型任务中使用多线程可以大大的加速程序的运行，即使在单核CPU上，这种加速主要就是利用了被浪费掉的阻塞时间。

IO密集时，大部分线程都被阻塞，故需要多配置线程数：

参考公式：CPU核数 / (1 - 阻塞系数)      阻塞系数在0.8 ~ 0.9左右

例如：8核CPU：8/ (1 - 0.9) = 80个线程数