Java--并发（三）------知识点整理

我会带着你远行 2023-07-10 08:30 69阅读 0赞

## 1、并行和并发有什么区别？ ##

**并发**

> 并发：一个处理器可以同时处理多个任务。这是逻辑上的同时发生。

指同一时刻只能够执行一条指令，但是多条指令被快速的进行切换，给人造成了它们同时执行的感觉。但在微观来说，并不同同时进行的，只是划分时间段，分别进行执行。

**并行**

> 并行：多个处理器同时处理多个不同的任务。这是物理上的同时发生。

在同一时刻，有多条指令在多个处理器上同时执行。

## 2、进程和线程区别是什么？ ##

> 一个程序由一个或多个进程组成，一个进程由一个或多个线程组成。

进程：是程序运行和资源分配的基本单位，一个程序至少有一个进程，一个进程至少有一个线程。进程在执行过程中拥有独立的内存单元，而多个线程共享内存资源，减少切换次数，从而效率更高。

线程：是进程的一个实体，是 cpu 调度和分派的基本单位，是比程序更小的能独立运行的基本单位。同一进程中的多个线程之间可以并发执行。

## 3、线程的6种状态 ##

[Java–多线程（一）------Java 线程的6种状态][Java_------Java _6]

## 4、创建线程的几种方式？ ##

[Java–多线程（二）------Java 线程创建的四种方式][Java_------Java]

## 5、Runnable 和 Callable 有什么区别？ ##

*  Runnable 接口中的 run() 方法的返回值是 void，它做的事情只是纯粹地去执行 run() 方法中的代码而已；
 *  Callable 接口中的 call() 方法是有返回值的，是一个泛型，和 Future、FutureTask 配合可以用来获取异步执行的结果。

## 6、sleep() 和 wait() 的区别？ ##

**1**、sleep() 方法正在执行的线程主动让出 cpu（然后 cpu 就可以去执行其他任务），在 sleep 指定时间后 cpu 再回到该线程继续往下执行（注意：sleep 方法只让出了 cpu，而并不会释放同步资源锁）；

wait() 方法则是指当前线程让自己暂时退让出同步资源锁，以便其他正在等待该资源的线程得到该资源进而运行，只有调用了 notify() 方法，之前调用 wait() 的线程才会解除 wait 状态，可以去参与竞争同步资源锁，进而得到执行。（注意：notify 的作用相当于叫醒睡着的人，而并不会给他分配任务，就是说 notify 只是让之前调用 wait 的线程有权利重新参与线程的调度）；

**2**、 sleep() 方法可以在任何地方使用，而 wait() 方法则只能在同步方法或同步块中使用；

**3**、sleep() 是线程类（Thread）的方法，调用会暂停此线程指定的时间，但监控依然保持，不会释放对象锁，到时间自动恢复；wait() 是 Object 的方法，调用会放弃对象锁，进入等待队列，待调用 notify()/notifyAll() 唤醒指定的线程或者所有线程，才会进入锁池，不再次获得对象锁才会进入运行状态。

## 7、线程的 run() 和 start() 有什么区别？ ##

1.  每个线程都是通过某个特定 Thread 对象所对应的方法 run() 来完成其操作的，方法 run() 称为线程体。通过调用 Thread 类的 start() 方法来启动一个线程；
2.  start() 方法来启动一个线程，真正实现了多线程运行。这时无需等待 run() 方法体代码执行完毕，可以直接继续执行下面的代码；这时此线程是处于就绪状态，并没有运行。然后通过此 Thread 类调用方法 run() 来完成其运行状态，这里方法 run() 称为线程体，它包含了要执行的这个线程的内容，run() 方法运行结束，此线程终止。然后 cpu 再调度其它线程；
3.  run() 方法是在本线程里的，只是线程里的一个函数，而不是多线程的。如果直接调用 run()，其实就相当于是调用了一个普通函数而已，直接待用 run() 方法必须等待 run() 方法执行完毕才能执行下面的代码，所以执行路径还是只有一条，根本就没有线程的特征，所以在多线程执行时要使用 start() 方法而不是 run() 方法。

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

execute()：只能执行 Runnable 类型的任务。

submit()：可以执行 Runnable 和 Callable 类型的任务。

Callable 类型的任务可以获取执行的返回值，而 Runnable 执行无返回值。

线程的执行有两种方式,一种是submit(runnable v)的形式,一种是execute(runnable b) 的形式。

不同的是submit可以返回一个future的实现类,相同的一点是submit底层其实也是调用的execute

> execute()：只能执行 Runnable 类型的任务。  
> submit()：可以执行 Runnable 和 Callable 类型的任务。  
> submit()能获取返回值（异步）以及处理Exception。execute()方法不行。

/**
     * submit(Runnable x) 返回一个future。可以用这个future来判断任务是否成功完成。请看下面：
     */
     Future future = pool.submit(new RunnableTest("Task2"));
     try {
        if(future.get()==null){//如果Future's get返回null，任务完成
              System.out.println("任务完成");
        }
    } catch (InterruptedException e) {
    } catch (ExecutionException e) {
         //否则我们可以看看任务失败的原因是什么
         System.out.println(e.getCause().getMessage());
     }
     
    
    /**
     * execute(Runnable x) 没有返回值。可以执行任务，但无法判断任务是否成功完成。
     */
    pool.execute(new RunnableTest("Task1"));

## 9、在 Java 程序中怎么保证多线程的运行安全？ ##

线程安全在三个方面体现：

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

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

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

## 10、Java 线程同步的几种方法？ ##

1.  使用 Synchronized 关键字；
2.  wait 和 notify；
3.  使用特殊域变量 volatile 实现线程同步；
4.  使用可重入锁实现线程同步；
5.  使用阻塞队列实现线程同步；
6.  使用信号量 Semaphore。

## 11、 什么是死锁？ ##

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。是操作系统层面的一个错误，是进程死锁的简称，最早在 1965 年由 Dijkstra 在研究银行家算法时提出的，它是计算机操作系统乃至整个并发程序设计领域最难处理的问题之一。

## 12、怎么检测一个线程是否拥有锁？ ##

在java.lang.Thread中有一个方法叫holdsLock(obj)，它返回true如果当且仅当当前线程拥有某个具体对象的锁。

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

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？ JDK中提供的ThreadLocal类正是为了解决这样的问题。 ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

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

ThreadLocal 是线程本地存储,在每个线程都创建了一个ThreadLocalMap对象,每个线程可以访问自己内部ThreadLocalMal对象内的value. 通过这种方式,避免资源在多线程见共享

如果使用ThreadLocal管理变量,则每一个使用该变量的线程都会获得该变量的副本  
副本之间相互独立,这样每一个线程都可以随意更改自己的变量副本,而不会对其他线程产生影响

**ThreadLocal类中提供了几个方法：**

1.public T get() \{ \}

2.public void set(T value) \{ \}

3.public void remove() \{ \}

4.protected T initialValue()\{ \}

get()方法是用来获取ThreadLocal在当前线程中保存的变量副本

set()用来设置当前线程中变量的副本

remove()用来移除当前线程中变量的副本

initialValue()是一个protected方法，一般是用来在使用时进行重写的，它是一个延迟加载方法

**经典的使用场景**是为每个线程分配一个 JDBC 连接 Connection。这样就可以保证每个线程的都在各自的 Connection 上进行数据库的操作，不会出现 A 线程关了 B线程正在使用的 Connection； 还有 Session 管理 等问题。

## 14、守护线程 ##

在Java中有两类线程：用户线程 (User Thread)、守护线程 (Daemon Thread)。  
守护线程和用户线程的区别在于：守护线程依赖于创建它的线程，而用户线程则不依赖。举个简单的例子：如果在main线程中创建了一个守护线程，当main方法运行完毕之后，守护线程也会随着消亡。而用户线程则不会，用户线程会一直运行直到其运行完毕。在JVM中，像垃圾收集器线程就是守护线程。

## 15、synchronized 和 volatile 的区别是什么？ ##

**synchronized关键字最主要的三种使用方式的总结**

**1、修饰实例方法**，作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁

**2、修饰静态方法**，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁 。也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份，所以对该类的所有对象都加了锁）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。

**3、修饰代码块**，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。 和 synchronized 方法一样，synchronized(this)代码块也是锁定当前对象的。synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。这里再提一下：synchronized关键字加到非 static 静态方法上是给对象实例上锁。另外需要注意的是：尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓冲功能！

**volatile**

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

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center]

**synchronized 和 volatile 的区别**

1、volatile 是变量修饰符；synchronized 是修饰类、方法、代码段。

2、volatile 仅能实现变量的修改可见性，不能保证原子性；而 synchronized 则可以保证变量的修改可见性和原子性。

3、volatile 不会造成线程的阻塞；synchronized 可能会造成线程的阻塞。

4、volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取； synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。

## 16、volatile关键字的作用 ##

> 在Java内存模型中，有main memory，每个线程也有自己的memory (例如寄存器)。为了性能，一个线程会在自己的memory中保持要访问的变量的副本。这样就会出现同一个变量在某个瞬间，在一个线程的memory中的值可能与另外一个线程memory中的值，或者main memory中的值不一致的情况。

**1、保证内存可见性**

volatile让变量每次在使用的时候，都从主存中取。而不是从各个线程的“工作内存”。

也就是说volatile变量对于每次使用，线程都能得到当前volatile变量的最新值。

**2、禁止指令重排序**

指令的执行顺序并不一定会像我们编写的顺序那样执行，为了保证执行上的效率，JVM可能会对指令进行重排序。

int i = 1;    //正常应该是先执行i=1
    int j = 2;    //然后执行j=2;

JVM会保证在单线程的情况下，重排序后的执行结果会和重排序之前的结果一致。但是在多线程的场景下就不一定了。

使用volatile关键字修饰inited变量,JVM就会阻止对inited相关的代码进行重排序.这样就能够按照既定的顺序指执行.

**3、不保证原子性**

对volatile修饰的变量进行的操作，不保证多线程安全

i ++;

在单线程的情况下，是线程安全的，如果i初始值为0，i++ 结果为1；

在多线程情况下，使用volatile修改遍历i，可能存在i的 结果不等于预期结果。

**原因：**

> 首先获取变量i的值  
> 将该变量的值+1  
> 将该变量的值写回到对应的主内存中

虽然每次获取 i 值的时候，也就是执行上述第一步的时候，都拿到的是主内存的最新变量值，但是在进行第二步 i+1 的时候，可能其他线程在此期间已经对 i 做了多次修改。

## 17、为什么wait, notify 和 notifyAll这些方法不在thread类里面？ ##

Java提供的锁是对象级的而不是线程级的，每个对象都有锁，通过线程获得。简单的说，由于wait，notify，notifyAll都是锁级别的操作，所以把他们定义在object类中因为锁属于对象。

## 18、interrupt、interrupted和isInterrupted的区别 ##

**interrupt（）**  
interrupt方法是用于中断线程的，调用该方法的线程的状态将被置为"中断"状态。注意：线程中断仅仅是设置线程的中断状态位，不会停止线程。所以当一个线程处于中断状态时，如果再由wait、sleep以及jion三个方法引起的阻塞，那么JVM会将线程的中断标志重新设置为false，并抛出一个InterruptedException异常，然后开发人员可以中断状态位“的本质作用-----就是程序员根据try-catch功能块捕捉jvm抛出的InterruptedException异常来做各种处理，比如如何退出线程。总之interrupt的作用就是需要用户自己去监视线程的状态位并做处理。”

**interrupted**：测试当前线程是否是中断状态，执行完清除中断状态

**isInterrupted**：测试Thread对象是否是中断状态，不清除中断状态

## 19、栈和堆的区别 ##

**什么是堆内存？**  
堆内存是java内存中的一种，它的作用是用于存储java中的对象和数组，当我们new一个对象或者创建一个数组的时候，就会在堆内存中开辟一段空间给它，用于存放。

**堆内存的特点是什么？**  
第一点：堆其实可以类似的看做是管道，或者说是平时去排队买票的情况差不多，所以堆内存的特点就是：先进先出，后进后出，也就是你先排队好，你先买票。

第二点：堆可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的，但缺点是，由于要在运行时动态分配内存，存取速度较慢。

**new对象在堆中如何分配？**  
由Java虚拟机的自动垃圾回收器来管理。

**栈内存**

**什么是栈内存**  
栈内存是Java的另一种内存，主要是用来执行程序用的，比如：基本类型的变量和对象的引用变量

**栈内存的特点**  
第一点：栈内存就好像一个矿泉水瓶，往里面放入东西，那马先放入的沉入底部，所以它的特点是：先进后出，后进先出  
第二点：存取速度比堆要快，仅次于寄存器，栈数据可以共享，但缺点是，存在栈中的数据大小与生存必须是确定的，缺乏灵活性

**栈内存分配机制**  
栈内存可以称为一级缓存，由垃圾回收器自动回收

**数据共享**  
例子：  
int a = 3;  
int b = 3;

**栈和堆的区别**

*  堆内存用来存放由new创建的对象和数组
 *  栈内存用来存放方法或者局部变量等
 *  堆是先进先出，后进后出
 *  栈是先进后出，后进先出
 *  共享性的不同：  
    栈内存是线程私有的  
    堆内存是所有线程共有的

## 20、如何避免死锁？ ##

死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。这是一个严重的问题，因为死锁会让你的程序挂起无法完成任务，

**死锁的发生必须满足以下四个条件：**

互斥条件：一个资源每次只能被一个进程使用。  
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。  
不剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。  
循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

避免死锁最简单的方法就是阻止循环等待条件，将系统中所有的资源设置标志位、排序，规定所有的进程申请资源必须以一定的顺序（升序或降序）做操作来避免死锁。

**避免死锁**

**加锁顺序**：当多个线程需要相同的一些锁，但是按照不同的顺序加锁，死锁就容易发生。  
按照顺序加锁是一种有效的死锁预防机制。但是，这种方式需要事先知道所有可能会用到的锁，但总有些时候是无法预知的。

**加锁时限**：当一个线程在尝试获取锁的过程中超过了这个时限则该线程应该放弃对该锁进行请求。

若一个线程没有在给定的时限内成功获得所有需要的锁，则会进行回退并释放所有已经获得的锁，然后等待一段随机的时间再重试。这段随机的等待时间让其它线程有机会尝试获取相同的这些锁，并且让该应用在没有获得锁的时候可以继续运行。

需要注意的是，由于存在锁的超时，所以我们不能认为这种场景就一定是出现了死锁。也可能是因为获得了锁的线程（导致其它线程超时）需要很长的时间去完成它的任务。

此外，如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁。如果只有两个线程，并且重试的超时时间设定为0到500毫秒之间，这种现象可能不会发生，但是如果是10个或20个线程情况就不同了。因为这些线程等待相等的重试时间的概率就高的多（或者非常接近以至于会出现问题）。

**死锁检测**：

死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。

每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。

当一个线程请求锁失败时，这个线程可以遍历锁的关系图看看是否有死锁发生

例如，线程A请求锁7，但是锁7这个时候被线程B持有，这时线程A就可以检查一下线程B是否已经请求了线程A当前所持有的锁。如果线程B确实有这样的请求，那么就是发生了死锁（线程A拥有锁1，请求锁7；线程B拥有锁7，请求锁1）。

当然，死锁一般要比两个线程互相持有对方的锁这种情况要复杂的多。线程A等待线程B，线程B等待线程C，线程C等待线程D，线程D又在等待线程A。线程A为了检测死锁，它需要递进地检测所有被B请求的锁。从线程B所请求的锁开始，线程A找到了线程C，然后又找到了线程D，发现线程D请求的锁被线程A自己持有着。这是它就知道发生了死锁。

下面是一幅关于四个线程（A,B,C和D）之间锁占有和请求的关系图。像这样的数据结构就可以被用来检测死锁。  
![在这里插入图片描述][2020040901055826.png]

那么当检测出死锁时，这些线程该做些什么呢？

一个可行的做法是释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。虽然有回退和等待，但是如果有大量的线程竞争同一批锁，它们还是会重复地死锁（编者注：原因同超时类似，不能从根本上减轻竞争）。

一个更好的方案是给这些线程设置优先级，让一个（或几个）线程回退，剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的，同一批线程总是会拥有更高的优先级。为避免这个问题，可以在死锁发生的时候设置随机的优先级。

## 21、Java中活锁和死锁有什么区别？ ##

任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试，失败，尝试，失败

活锁和死锁类似，不同之处在于处于活锁的线程或进程的状态是不断改变的，活锁可以认为是一种特殊的饥饿。一个现实的活锁例子是两个人在狭小的走廊碰到，两个人都试着避让对方好让彼此通过，但是因为避让的方向都一样导致最后谁都不能通过走廊。简单的说就是，活锁和死锁的主要区别是前者进程的状态可以改变但是却不能继续执行。

## 22、JVM中哪个参数是用来控制线程的栈堆栈小的 ##

\-Xss参数用来控制线程的堆栈大小。

## 23、有三个线程T1，T2，T3，怎么确保它们按顺序执行？ ##

在多线程中有多种方法让线程按特定顺序执行

1、你可以用线程类的join()方法在一个线程中启动另一个线程，另外一个线程完成该线程继续执行。为了确保三个线程的顺序你应该先启动最后一个(T3调用T2，T2调用T1)，这样T1就会先完成而T3最后完成。

2、ExecutorService executor = Executors.newSingleThreadExecutor()

java5以后提供的一个多线程操作方法，创建一个只有一个线程的线程池操作，会创建一个线程队列，按FIFO的顺序执行里面的线程

## 24、如果你提交任务时，线程池队列已满。会时发会生什么？ ##

当线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：

*  ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。注：默认策略！
 *  ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常。
 *  ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）
 *  ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务

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

**使用线程池的好处**

**降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。

**提高响应速度**。当任务到达时，任务可以不需要的等到线程创建就能立即执行。

**提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

两个方法都可以向线程池提交任务，execute()方法的返回类型是void，它定义在Executor接口中, 而submit()方法可以返回持有计算结果的Future对象，它定义在ExecutorService接口中，它扩展了Executor接口，其它线程池类像ThreadPoolExecutor和ScheduledThreadPoolExecutor都有这些方法。

## 26、单例模式的双检锁是什么？ ##

## 27、写出3条你遵循的多线程最佳实践 ##

*  给你的线程起个有意义的名字。  
    这样可以方便找bug或追踪。OrderProcessor, QuoteProcessor or TradeProcessor 这种名字比 Thread-1. Thread-2 and Thread-3 好多了，给线程起一个和它要完成的任务相关的名字，所有的主要框架甚至JDK都遵循这个最佳实践。
 *  避免锁定和缩小同步的范围  
    锁花费的代价高昂且上下文切换更耗费时间空间，试试最低限度的使用同步和锁，缩小临界区。因此相对于同步方法我更喜欢同步块，它给我拥有对锁的绝对控制权。
 *  多用同步类少用wait 和 notify  
    首先，CountDownLatch, Semaphore, CyclicBarrier 和 Exchanger 这些同步类简化了编码操作，而用wait和notify很难实现对复杂控制流的控制。其次，这些类是由最好的企业编写和维护在后续的JDK中它们还会不断优化和完善，使用这些更高等级的同步工具你的程序可以不费吹灰之力获得优化。
 *  多用并发集合少用同步集合  
    这是另外一个容易遵循且受益巨大的最佳实践，并发集合比同步集合的可扩展性更好，所以在并发编程时使用并发集合效果更好。如果下一次你需要用到map，你应该首先想到用ConcurrentHashMap。

## 28、Java多线程中调用wait() 和 sleep()方法有什么不同？ ##

Java程序中wait 和 sleep都会造成某种形式的暂停，它们可以满足不同的需要。wait()方法用于线程间通信，如果等待条件为真且其它线程被唤醒时它会释放锁，而sleep()方法仅仅释放CPU资源或者让当前线程停止执行一段时间，但不会释放锁。

## 28、请介绍一下 ThreadPoolExecutor 类？ ##

线程池实现类 ThreadPoolExecutor 是 Executor 框架最核心的类

**hreadPoolExecutor 类分析**

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

/**
         * 用给定的初始参数创建一个新的ThreadPoolExecutor。
         */
        public ThreadPoolExecutor(int corePoolSize,//线程池的核心线程数量
                                  int maximumPoolSize,//线程池的最大线程数
                                  long keepAliveTime,//当线程数大于核心线程数时，多余的空闲线程存活的最长时间
                                  TimeUnit unit,//时间单位
                                  BlockingQueue 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;
        }

下面这些对创建 非常重要，在后面使用线程池的过程中你一定会用到！所以，务必拿着小本本记清楚。

**ThreadPoolExecutor 3 个最重要的参数：**

**corePoolSize** :

核心线程数。在创建线程池之后，默认情况下线程池中并没有任何的线程，而是等待任务到来才创建线程去执行任务，当线程池中的线程数目达到 corePoolSize后，新来的任务将会被添加到缓存队列中，也就是那个workQueue

PS：很多人不知道这个数该填多少合适，其实也不必特别纠结，根据实际情况填写就好，实在不知道，就按照阿里工程师的写法取下列值就好了：

int NUMBER_OF_CORES = Runtime.getRuntime().availableProcessors();

> java.lang.Runtime.availableProcessors() 方法: 返回Java虚拟机的可用的处理器数量。

**创建多少线程比较合适?**

我们知道创建多少线程能够将硬件的利用率达到最高才是最好的线程数。

> 从线程的应用场景来分析， 由于IO操作比CPU计算耗时要久的多的，如果我们一段程序有IO操作和CPU计算 我们可以称之为：IO密集型计算。 程序中没有IO操作，只有CPU的话，称之为CPU密集型程序。
> 
> 1.  IO密集计算，如何将硬件利用率达到极致呢 我们将 R = IO耗时 / CPU耗时 我们从上面的例子来看 如果IO耗时/CPU耗时 = 10 （我们平常可以用工具apm来统计这个比例） 创建线程A 执行io操作 我们希望IO操作的时候 CPU不能闲着 所以就应该创建10个线程去执行CPU计算 当Io操作完毕后刚好CPU也执行完毕 ，他们的利用率都是百分之100 在执行这段代码的时候。这个例子我们要创建 1+ 10 = 11个线程执行起来效率更高，于是我们就得到了公式: 1+ I/O耗时/CPU耗时，如果是多核CPU最佳线程数 =CPU 核数 \* \[ 1 +（I/O 耗时 / CPU耗时）
> 2.  CPU密集型，这个就很简单了 CPU的核数 = 线程数就行，一般我们会设置 CPU核数+1 防止由于其他因素导致线程阻塞等。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center 1]

> 多核CPU最佳线程数 =CPU 核数 \* \[ 1 +（I/O 耗时 / CPU耗时）

**maximumPoolSize** :

线程池中的最大线程数。表示线程池中最多可以创建多少个线程。

很多人以为它的作用是这样的：”当线程池中的任务数超过 corePoolSize 后，线程池会继续创建线程，直到线程池中的线程数小于maximumPoolSize“，其实这种理解是完全错误的。

它真正的作用是：当线程池中的线程数等于 corePoolSize 并且 workQueue 已满，这时就要看当前线程数是否大于 maximumPoolSize，如果小于maximumPoolSize 定义的值，则会继续创建线程去执行任务， 否则将会调用去相应的任务拒绝策略来拒绝这个任务。

另外超过 corePoolSize的线程被称做"Idle Thread", 这部分线程会有一个最大空闲存活时间(keepAliveTime)，如果超过这个空闲存活时间还没有任务被分配，则会将这部分线程进行回收。

**workQueue**: 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。

**ThreadPoolExecutor其他常见参数:**

**keepAliveTime**

当线程池中的线程数量大于 corePoolSize 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 keepAliveTime才会被回收销毁；

**unit** :

keepAliveTime 参数的时间单位。

参数keepAliveTime的时间单位，共7种取值，在TimeUtil中定义：

TimeUnit.DAYS;              //天
    TimeUnit.HOURS;             //小时
    TimeUnit.MINUTES;           //分钟
    TimeUnit.SECONDS;           //秒
    TimeUnit.MILLISECONDS;      //毫秒
    TimeUnit.MICROSECONDS;      //微妙
    TimeUnit.NANOSECONDS;       //纳秒

**threadFactory**

线程工厂。用来为线程池创建线程，当我们不指定线程工厂时，线程池内部会调用Executors.defaultThreadFactory()创建默认的线程工厂，其后续创建的线程优先级都是Thread.NORM\_PRIORITY。如果我们指定线程工厂，我们可以对产生的线程进行一定的操作。

**handler** :饱和策略。

拒绝执行策略。当线程池的缓存队列已满并且线程池中的线程数目达到maximumPoolSize，如果还有任务到来就会采取任务拒绝策略，通常有以下四种策略：

**ThreadPoolExecutor.AbortPolicy**：抛出 RejectedExecutionException来拒绝新任务的处理。

**ThreadPoolExecutor.CallerRunsPolicy**：调用执行自己的线程运行任务，也就是直接在调用execute方法的线程中运行(run)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。另外，这个策略喜欢增加队列容量。如果您的应用程序可以承受此延迟并且你不能任务丢弃任何一个任务请求的话，你可以选择这个策略。

**ThreadPoolExecutor.DiscardPolicy**： 不处理新任务，直接丢弃掉。

**ThreadPoolExecutor.DiscardOldestPolicy**： 此策略将丢弃最早的未处理的任务请求（重复此过程）。

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

## 29、ThreadPoolExecutor 创建方法最佳实践？ ##

在《阿里巴巴 Java 开发手册》“并发处理”这一章节，明确指出线程资源必须通过线程池提供，不允许在应用中自行显示创建线程。

> 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源开销，解决资源不足的问题。如果不使用线程池，有可能会造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

另外《阿里巴巴 Java 开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

> Executors 返回线程池对象的弊端如下：  
> FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列长度为 Integer.MAX\_VALUE,可能堆积大量的请求，从而导致 OOM。  
> CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX\_VALUE ，可能会创建大量线程，从而导致 OOM。

**方式一：通过ThreadPoolExecutor构造函数实现（推荐）**

![在这里插入图片描述][20200815162444905.png_pic_center]

**方式二：通过 Executor 框架的工具类 Executors 来实现 我们可以创建三种类型的**

ThreadPoolExecutor：

FixedThreadPool  
SingleThreadExecutor  
CachedThreadPool

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center 2]

## 30、介绍一下Atomic 原子类？ ##

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

所以，所谓原子类说简单点就是具有原子/原子操作特征的类。

并发包 java.util.concurrent 的原子类都存放在`java.util.concurrent.atomic`

**然已经有了synchronized关键字和lock，为什么还要引入原子类呢？或者什么场景下使用原子类更好呢？**

在很多时候，我们需要的仅仅是一个简单的、高效的、线程安全的递增或者递减方案，这个方案一般需要满足以下要求：

1、 简单：操作简单，底层实现简单

2、 高效：占用资源少，操作速度快

3、 安全：在高并发和多线程环境下要保证数据的正确性

对于是需要简单的递增或者递减的需求场景，使用synchronized关键字和lock固然可以实现，但代码写的会略显冗余，且性能会有影响，此时用原子类更加方便。

根据操作的数据类型，可以将JUC包中的原子类分为4类

**基本类型**

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

AtomicInteger：整型原子类  
AtomicLong：长整型原子类  
AtomicBoolean ：布尔型原子类  
**数组类型**

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

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

AtomicReference：引用类型原子类  
AtomicReferenceFieldUpdater：原子更新引用类型里的字段  
AtomicMarkableReference ：原子更新带有标记位的引用类型  
**对象的属性修改类型**

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

## 31、AQS 介绍 ##

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

AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。

> AQS就是一个并发包的基础组件，用来实现各种锁，各种同步组件的。它包含了state变量、加锁线程、等待队列等并发中的核心组件

**state:** AQS对象内部有一个核心的变量叫做state，是int类型的，代表了加锁的状态。初始状态下，这个state的值是0。

**加锁线程变量:** AQS内部还有一个关键变量，用来记录当前加锁的是哪个线程，初始化状态下，这个变量是null

**等待队列：** 通过内置的FIFO队列来完成获取资源线程的排队工作。

## 32、ReentrantLock加锁和释放锁的底层原理 ##

ReentrantLock内部包含了一个AQS对象，也就是AbstractQueuedSynchronizer类型的对象。  
这个AQS对象就是ReentrantLock可以实现加锁和释放锁的关键性的核心组件

1、AQS对象内部有一个核心的变量叫做state，是int类型的，代表了加锁的状态。  
初始状态下，这个state的值是0。

2、这个AQS内部还有一个关键变量，用来记录当前加锁的是哪个线程，初始化状态下，这个变量是null

3、线程1跑过来调用ReentrantLock的lock()方法尝试进行加锁，这个加锁的过程，直接就是用CAS操作将state值从0变为1

4、一旦线程1加锁成功了之后，就可以设置当前加锁线程是自己

5、ReentrantLock（是一个可重入锁），可以对一个ReentrantLock对象多次执行lock()加锁和unlock()释放锁，也就是可以对一个锁加多次，叫做可重入加锁。每次加锁就是把state的值给累加1

6、线程2请求加锁，发现state变量不为0，加锁失败，线程2会将自己放入AQS中的一个等待队列，因为自己尝试加锁失败了，此时就要将自己放入队列中来等待，等待线程1释放锁之后，自己就可以重新尝试加锁了

7、线程1释放锁，AQS内的state变量的值递减1，如果state值为0，则彻底释放锁，会将“加锁线程”变量也设置为null！

8、等待队列的队头唤醒线程2重新尝试加锁，线程2现在就重新尝试加锁，这时还是用CAS操作将state从0变为1，此时就会成功，成功之后代表加锁成功，就会将state设置为1。此外，还要把“加锁线程”设置为线程2自己，同时线程2自己就从等待队列中出队了

## 33、synchronized和Lock有什么区别？ ##

synchronized 早期的实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大，但是在 Java 6 中对 synchronized 进行了非常多的改进。

1、ReentrantLock 使用起来比较灵活，但是必须有释放锁的配合动作；

2、ReentrantLock 必须手动获取与释放锁，而 synchronized 不需要手动释放和开启锁；

3、ReentrantLock 只适用于代码块锁，而 synchronized 可用于修饰方法、代码块等。

4、ReentrantLock 标记的变量不会被编译器优化；synchronized 标记的变量可以被编译器优化。

5、 两者都是可重入锁

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

6、synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API

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

7、ReenTrantLock 比 synchronized 增加了一些高级功能

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

8、性能已不是选择标准

在JDK1.6之前，synchronized 的性能是比 ReenTrantLock 差很多。

JDK1.6 之后，synchronized 和 ReenTrantLock 的性能基本是持平了。

提倡在synchronized能满足你的需求的情况下，优先考虑使用synchronized关键字来进行同步

class X {
        private final ReentrantLock lock = new ReentrantLock();
        // ...
     
        public void m() {
          lock.lock();  // 加锁
          try {
            // ... 函数主题
          } finally {
            lock.unlock() //解锁
          }
        }
    }

## 33、重入锁与不可重入锁之间的区别与性能差异？ ##

**可重入锁**

指在同一个线程在外层方法获取锁的时候，进入内层方法会自动获取锁。

为了避免死锁的发生，JDK 中基本都是可重入锁。

--------------------

如果你觉得本篇文章对你有所帮助的话，麻  
烦请点击头像右边的关注按钮，谢谢！

技术在交流中进步，知识在分享中传播

[Java_------Java _6]: https://blog.csdn.net/qq_29914837/article/details/103811207
[Java_------Java]: https://blog.csdn.net/qq_29914837/article/details/104596888
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200815151858685.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70#pic_center
[2020040901055826.png]: https://img-blog.csdnimg.cn/2020040901055826.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20201117222538837.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70#pic_center
[20200815162444905.png_pic_center]: https://img-blog.csdnimg.cn/20200815162444905.png#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20200815162524216.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70#pic_center