多线程相关

最新推荐文章于 2024-07-05 22:28:16 发布

LALALA3_3

最新推荐文章于 2024-07-05 22:28:16 发布

阅读量306

点赞数

分类专栏： java

本文链接：https://blog.csdn.net/LALALA3_3/article/details/105736679

版权

java 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1.3Java多线程
关于 Java多线程，在面试的时候，问的比较多的就是①悲观锁和乐观锁、②synchronized和lock区别以及volatile和synchronized的区别，③可重入锁与非可重入锁的区别、④多线程是解决什么问题的、⑤线程池解决什么问题、⑥线程池的原理、⑦线程池使用时的注意事项、⑧AQS原理、⑨ReentranLock源码，设计原理，整体过程等等问题。
面试官在多线程这一部分很可能会问你有没有在项目中实际使用多线程的经历。所以，如果你在你的项目中有实际使用Java多线程的经历的话，会为你加分不少哦！
在此之前先说一些简单的问题：

1、并发编程三要素？
1）原子性
原子性指的是一个或者多个操作，要么全部执行并且在执行的过程中不被其他操作打断，要么就全部都不执行。
2）可见性
可见性指多个线程操作一个共享变量时，其中一个线程对变量进行修改后，其他线程可以立即看到修改的结果。
3）有序性
有序性，即程序的执行顺序按照代码的先后顺序来执行。

3、多线程的价值？
1）发挥多核CPU的优势
多线程，可以真正发挥出多核CPU的优势来，达到充分利用CPU的目的，采用多线程的方式去同时完成几件事情而不互相干扰。
2）防止阻塞
从程序运行效率的角度来看，单核CPU不但不会发挥出多线程的优势，反而会因为在单核CPU上运行多线程导致线程上下文的切换，而降低程序整体的效率。但是单核CPU我们还是要应用多线程，就是为了防止阻塞。试想，如果单核CPU使用单线程，那么只要这个线程阻塞了，比方说远程读取某个数据吧，对端迟迟未返回又没有设置超时时间，那么你的整个程序在数据返回回来之前就停止运行了。多线程可以防止这个问题，多条线程同时运行，哪怕一条线程的代码执行读取数据阻塞，也不会影响其它任务的执行。
3）便于建模
这是另外一个没有这么明显的优点了。假设有一个大的任务A，单线程编程，那么就要考虑很多，建立整个程序模型比较麻烦。但是如果把这个大的任务A分解成几个小任务，任务B、任务C、任务D，分别建立程序模型，并通过多线程分别运行这几个任务，那就简单很多了。

4.什么是程序、线程、什么是进程，线程和进程之间的区别:
程序是一个指令集是一个静态的概念
进程是系统中正在运行的一个程序，程序一旦运行就是进程（操作系统调度程序，是一个动态的概念）。
线程是进程的一个实体，是进程的一条执行路径。
线程是进程的一个特定执行路径（进程内可能有多条执行路径）。当一个线程修改了进程的资源，它的兄弟线程可以立即看到这种变化。
（现代操作系统在运行一个程序时，会为其创建一个进程。例如启动一个java程序，操作系统就会创建一个Java进程。现代操作系统调度cpu的最小单位是线程，也叫轻量级进程(Light weight process)，在一个进程里可以创建多个线程，这些线程都拥有各自的计数器，堆栈和局部变量等属性，并且能够访问共享的内存变量，处理器在这些线程上高速切换，让使用者感受到这些线程在同时执行。
线程的执行可以分为两类：
1.用户级线程（User-Level Thread）
2.内核级线程(Kernel-Level Thread)
在理解线程分类之前需要先了解系统的用户空间User space与内核空间Kernel Space两个概念。
内核空间用于运行操作系统核心组件，比如内存管理组件，IO交互组件，文件管理、中断管理组件等，同时驱动程序（Driver）也运行在内核空间。
用户空间，用于运行普通应用程序。
即内核空间是内核代码运行的地方，用户空间是用户程序代码运行的地方。
当进程运行在内核空间时就处于内核态，当进程运行在用户空间时就处于用户态。

进程一旦需要创建线程，需要依赖底层的内核，此时进程的空间必然会进行状态的切换，线程的工作空间需要陷入到内核当中去，只有进入到内核当中才拥有创建线程、调度、管理它的权限，否则在用户空间没有资格去操作内核空间中的内容。
在这里插入图片描述
ULT用户级线程、KLT内核级线程
JVM中用的是KLT这种线程模型
内核线程
内核线程就是直接由操作系统内核支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身。
程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间 1 ： 1 的关系称为一对一的线程模型，如下图所示。
在这里插入图片描述
由于有内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作，但是轻量级进程具有它局限性，主要有如下两点

线程的创建、销毁等操作，都需要进行系统调用，而系统调用的代价相对较高，需要在用户态和内核态之间来回切换。
每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（比如内核线程的栈空间），因此一个系统支持轻量级线程的数量是有限的。

用户线程
从广义上讲，一个线程只要不是内核线程，就可以认为是用户线程。从狭义上讲，用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，并且可以支持规模更大的线程数量。这种进程与用户线程之间 1 ： N 的关系称为一对多的线程模型，如下图所示。
在这里插入图片描述
使用用户线程的优势在于不需要内核支援，劣势也在于没有内核的支援，所有的线程操作都需要用户程序自己处理。线程的创建、切换和调度都是需要考虑的问题。因而使用用户线程实现的程序都比较复杂，除了以前在不支持多线程的操作系统中的多线程程序与少数有特殊需求的程序外，现在使用用户线程的程序越来越少了。

Java 线程在 JDK1.2之前，是基于称为“绿色线程”的用户线程实现的，而在 JDK 1.2 中，线程模型替换为基于操作系统原生线程模型来实现，因此，在目前的 JDK 版本中，操作系统支持怎样的线程模型，在很大程度上决定了 Java 虚拟机的线程是怎样映射的
在这里插入图片描述
Java线程底层执行原理：
Java线程创建是依赖于系统内核，通过JVM调用系统库创建内核线程，内核线程与Java-Thread是1：1的映射关系。
JVM在new一个线程时，在JVM底层会调用Linux里的P-Thread函数库，这个库里封装了大量的关于线程的操作(比如线程的创建、阻塞、调度等)这些操作都依赖于这个第三方库、库调度器，库调度器会在内核空间里创建一个线程，创建线程之后会在线程表里维护一条记录，这条记录会给操作系统底层实时的去调度，与此同时，会在内核空间里给内核线程去创建一个内核线程栈，也就是在操作系统里开辟一块空间专门用来存储对应的线程。

实际上线程的实现与 Java 无关，由平台所决定，Java 所做的是将 Thread 对象映射到操作系统所提供的线程上面去，对外提供统一的操作接口，向程序员隐藏了底层的细节，使程序员感觉在哪个平台上编写的有关于线程的代码都是一样的。这也是 Java 这门语言诞生之初的核心思想，一处编译，到处运行，只面向虚拟机，实现所谓的平台无关性，而这个平台无关性就是由虚拟机为我们提供的。

（创建大量线程会造成大量上下文切换、状态切换，java中尽量避免线程创建出来之后没做什么就被销毁了，避免重复创建线程，因为创建线程的过程很复杂、很慢，所以就引出了线程池）
什么是多线程的上下文切换
多线程的上下文切换是指CPU控制权由一个已经正在运行的线程切换到另外一个就绪并等待获取CPU执行权的线程的过程。
）
不可变对象对多线程有什么帮助
前面有提到过的一个问题，不可变对象保证了对象的内存可见性，对不可变对象的读取不需要进行额外的同步手段，提升了代码执行效率。

进程和线程之间的区别：

进程是资源分配的最小单位，线程是程序执行的最小单位。
进程有自己的独立地址空间，每启动一个进程，系统就会为它分配地址空间，建立数据表来维护代码段、堆栈段和数据段，这种操作非常昂贵。而线程是共享进程中的数据的，使用相同的地址空间，因此CPU切换一个线程的花费远比进程要小很多，同时创建一个线程的开销也比进程要小很多。
线程之间的通信更方便，同一进程下的线程共享全局变量、静态变量等数据，而进程之间的通信需要以通信的方式（IPC)进行。不过如何处理好同步与互斥是编写多线程程序的难点。
但是多进程程序更健壮，多线程程序只要有一个线程死掉，整个进程也死掉了，而一个进程死掉并不会对另外一个进程造成影响，因为进程有自己独立的地址空间。

5、创建线程的有哪些方式？
1）继承Thread类创建线程类
2）通过Runnable接口创建线程类
3）通过Callable和Future创建线程
4）通过线程池创建
继承Thead类
1）创建继承自Thread类的子类并重写Thread类的run方法
2）通过创建该子类的对象，获得线程对象
3）调用线程对象的start()方法启动线程

package com.demo.thread;

public class ThreadDemo extends Thread {

    public ThreadDemo(String name) {
        super(name);
    }

    @Override
    public void run() {
        int i = 100;
        while (i-- > 0) {
            System.out.println(String.format("%s：第%d次运行", getName(), i));
        }
    }

    public static void main(String[] args) {
        ThreadDemo demo = new ThreadDemo("A");
        ThreadDemo demo2 = new ThreadDemo("B");
        demo.start();
        demo2.start();
    }

}

实现Runnable接口
1）定义Runnable接口的实现类并重写run()方法
2）创建实现类的对象，并以此Runnable对象作为Thread的target创建Thread对象，即线程对象
3）调用线程对象的start()方法启动线程

 package com.demo.thread;

public class RunnableDemo implements Runnable {

    private String name;

    public RunnableDemo(String name) {
        this.name = name;
    }

    @Override
    public void run() {
        int i = 100;
        while (i-- > 0) {
            System.out.println(String.format("%s：第%d次运行", name, i));
        }
    }

    public static void main(String[] args) {
        RunnableDemo demoA = new RunnableDemo("A");
        RunnableDemo demoB = new RunnableDemo("B");
        new Thread(demoA).start();
        new Thread(demoB).start();
    }

}

实现Callable接口
1）创建Callable接口的实现类并实现call()方法,该方法具有返回值
2）创建Callable实现类的对象，使用该Callable实例创建FutureTask的对象
3）以FutureTask对象作为Thread的target创建Thread对象，获得线程对象
4）调用线程对象的start()方法启动线程
5）调用FutureTask对象的get()方法获得线程运行结果
（Runnable接口中的run()方法的返回值是void，它做的事情只是纯粹地去执行run()方法中的代码而已；Callable接口中的call()方法是有返回值的，是一个泛型，和Future、FutureTask配合可以用来获取异步执行的结果。
这其实是很有用的一个特性，因为多线程相比单线程更难、更复杂的一个重要原因就是因为多线程充满着未知性，某条线程是否执行了？某条线程执行了多久？某条线程执行的时候我们期望的数据是否已经赋值完毕？无法得知，我们能做的只是等待这条多线程的任务执行完毕而已。而Callable+Future/FutureTask却可以获取多线程运行的结果，可以在等待时间太长没获取到需要的数据的情况下取消该线程的任务，真的是非常有用。）
注：Callable必须要借助FutureTask封装才能启动线程（线程池中的submit方法里面也是用了FutureTask）

package com.demo.thread;

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;

public class CallableDemo implements Callable<String> {

    private String name;

    public CallableDemo(String name) {
        this.name = name;
    }

    @Override
    public String call() throws Exception {
        int i = 10;
        while (i-- > 0) {
            System.out.println(String.format("%s：第%d次运行", name, i));
        }
        return String.format("%s：运行结束", name);
    }

    public static void main(String[] args) throws InterruptedException, ExecutionException {
        CallableDemo demoA = new CallableDemo("A");
        FutureTask<String> futureTaskA = new FutureTask<>(demoA);
        Thread threadA = new Thread(futureTaskA);
        CallableDemo demoB = new CallableDemo("B");
        FutureTask<String> futureTaskB = new FutureTask<>(demoB);
        Thread threadB = new Thread(futureTaskB);
        threadA.start();
        threadB.start();
        System.out.println(futureTaskA.get());
        System.out.println(futureTaskB.get());
    }

}

6、创建线程的三种方式的对比？
1）采用实现Runnable、Callable接口的方式创建多线程。
优势是：
线程类只是实现了Runnable接口或Callable接口，还可以继承其他类。
在这种方式下，多个线程可以共享同一个target对象，所以非常适合多个相同线程来处理同一份资源的情况，从而可以将CPU、代码和数据分开，形成清晰的模型，较好地体现了面向对象的思想。
劣势是：
编程稍微复杂，如果要访问当前线程，则必须使用Thread.currentThread()方法。
2）使用继承Thread类的方式创建多线程
优势是：
编写简单，如果需要访问当前线程，则无需使用Thread.currentThread()方法，直接使用this即可获得当前线程。
劣势是：
线程类已经继承了Thread类，所以不能再继承其他父类。
3）Runnable和Callable的区别
Callable规定（重写）的方法是call()，Runnable规定（重写）的方法是run()。
Callable的任务执行后可返回值，而Runnable的任务是不能返回值的。
Call方法可以抛出异常，run方法不可以。
运行Callable任务可以拿到一个Future对象，表示异步计算的结果。它提供了检查计算是否完成的方法，以等待计算的完成，并检索计算的结果。通过Future对象可以了解任务执行情况，可取消任务的执行，还可获取执行结果。
（Callable是类似于Runnable的接口，实现Callable接口的类和实现Runnable的类都是可被其它线程执行的任务。）

什么是Future,什么是FutureTask：
Future：
在并发编程中，我们经常用到非阻塞的模型，在之前的多线程的三种实现中，不管是继承thread类还是实现runnable接口，都无法保证获取到之前的执行结果。通过实现Callback接口，并用Future可以来接收多线程的执行结果。
**Future表示一个可能还没有完成的异步任务的结果，**针对这个结果可以添加Callback以便在任务执行成功或失败后作出相应的操作。
FutureTask：
FutureTask表示一个异步运算的任务。FutureTask里面可以传入一个Callable的具体实现类，可以对这个异步运算的任务的结果进行等待获取、判断是否已经完成、取消任务等操作。
Future就是对于具体的Runnable或者Callable任务的执行结果进行取消、查询是否完成、获取结果。也就是说Future提供了三种功能：1）判断任务是否完成；2）能够中断任务；3）能够获取任务执行结果。而FutureTask是Future的实现，FutureTask对象可以对实现了Callable和Runnable的对象进行包装，由于FutureTask也是实现了Runnable接口所以它可以提交给Executor来执行即FutureTask也可以放入线程池中。
FutureTask实现了Runnable和Future

7.线程的生命周期及5种状态
线程的生命周期如图：
在这里插入图片描述

将线程映射到操作系统底层需执行Thread.start()进行映射操作(会调用整个OS(操作系统)的库)
上图中执行完成到终止的过程中，执行完成之后会将内核中线程栈这块空间清理掉进行gc，将这块栈空间和线程表里对应的记录都清理掉

Java线程具有五中基本状态:
1）新建状态（New）：当线程对象对创建后，即进入了新建状态，如：Thread t = new MyThread()；

2）就绪状态（Runnable）：当调用线程对象的start()方法（t.start();），线程即进入就绪状态。处于就绪状态的线程，只是说明此线程已经做好了准备，随时等待CPU调度执行，并不是说执行了t.start()此线程立即就会执行；

3）运行状态（Running）：当CPU开始调度处于就绪状态的线程时，此时线程才得以真正执行，即进入到运行状态。注：就绪状态是进入到运行状态的唯一入口，也就是说，线程要想进入运行状态执行，首先必须处于就绪状态中；

4）阻塞状态（Blocked）：处于运行状态中的线程由于某种原因，暂时放弃对CPU的使用权，停止执行，此时进入阻塞状态，直到其进入到就绪状态，才有机会再次被CPU调用以进入到运行状态。

根据阻塞产生的原因不同，阻塞状态又可以分为三种：

a.等待阻塞：运行状态中的线程执行wait()方法，使本线程进入到等待阻塞状态；
b.同步阻塞 – 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态；
c.其他阻塞 – 通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

5）死亡状态（Dead）：线程执行完了或者因异常退出了run()方法，该线程结束生命周期。

这里说一下 Java多线程的就绪、运行和死亡状态
就绪状态转换为运行状态：当此线程得到处理器资源即cpu分配了时间片（cpu是基于时间片轮询的方式）；
运行状态转换为就绪状态：当此线程主动调用yield()方法或在运行过程中失去处理器资源。
运行状态转换为死亡状态：当此线程线程执行体执行完毕或发生了异常。

此处需要特别注意的是：当调用线程的yield()方法时，线程从运行状态转换为就绪状态，但接下来CPU调度就绪状态中的哪个线程具有一定的随机性，因此，可能会出现A线程调用了yield()方法后，接下来CPU仍然调度了A线程的情况。

8.sleep方法和wait方法有什么区别?
sleep方法：
　　属于Thread类中的静态方法；sleep()方法可以在任何地方中使用；会导致程序暂停执行指定的时间，让出cpu给其他线程，但是他的监控状态依然保持着，当指定时间到了之后就会继续执行；在调用sleep方法的过程中，线程不会释放对象锁。（只会让出CPU，不会导致锁行为的改变）；sleep必须捕获异常
wait方法：
属于Object类中的实例方法；wait()方法必须要在同步方法或者同步块中调用，也就是必须已经获得对象锁；在调用wait方法的时候，线程会释放占有的对象锁（使得其他线程可以使用同步控制块或者方法），进入等待此对象的等待锁定池，等待下次获取资源，只有针对此对象调用notify/notifyAll方法后本线程才会进入对象锁定池准备获取对象锁并再次获得cpu时间片进入运行状态（不仅让出CPU，还释放已经占有的同步资源锁）；wait，notify，notifyAll不需要捕获异常（注：调用了notify方法后不会立即执行，得拿到锁）
总结：
其实两者都可以让线程暂停一段时间,但是本质的区别是一个线程的运行状态控制,一个是线程之间的通讯的问题

Notify和notifyAll的区别：
NotifyAll()会唤醒所有的线程，notify()只会唤醒一个线程，notifyAll()调用后，会将全部线程由等待池移到锁池，然后参与锁的竞争，竞争成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争。而notify()只会唤醒一个线程，具体唤醒哪个线程是由虚拟机控制

为什么wait()方法和notify()/notifyAll()方法要在同步块中被调用
这是JDK强制的，wait()方法和notify()/notifyAll()方法在调用前都必须先获得对象的锁

为什么这些操作线程的方法(wait(),notify(),notifyAll())定义在Object类中？
因为这些方法在使用时必须标明所属的锁，而锁又可以是任意对象，能被任意对象调用的方法一定定义在Object类中

10.怎么唤醒一个阻塞的线程
如果线程是因为调用了wait()、sleep()或者join()方法而导致的阻塞，可以中断线程，并且通过抛出InterruptedException来唤醒它；如果线程遇到了IO阻塞，无能为力，因为IO是操作系统实现的，Java代码并没有办法直接接触到操作系统。

join、yield、wait、sleep方法区别理解
join()
子线程join到主线程（启动程序的线程，比如c语言执行main函数的线程）。你的问题可能在于没有理解join，阻塞线程仅仅是一个表现，而非目的。其目的是等待当前线程执行完毕后，”计算单元”与主线程汇合。即主线程与子线程汇合之意。
main是主线程，在main中创建了thread线程，在main中调用了thread.join()，那么等thread结束后再执行main代码。

在很多情况下，主线程生成并起动了子线程，如果子线程里要进行大量的耗时的运算，主线程往往将于子线程之前结束，但是如果主线程处理完其他的事务后，需要用到子线程的处理结果，也就是主线程需要等待子线程执行完成之后再结束，这个时候就要用到join()方法了。

“等待该线程终止。”

解释一下，是主线程等待子线程的终止。也就是在子线程调用了join()方法后面的代码，只有等到子线程结束了才能执行。
测试代码如下所示：

public class TestJoin {
 
    public static void main(String[] args) {
        Thread thread = new Thread(new JoinDemo());
        thread.start();
 
        for (int i = 0; i < 20; i++) {
            System.out.println("主线程第" + i + "次执行！");
            if (i >= 2)
                try {
             // t1线程合并到主线程中，主线程停止执行过程，转而执行t1线程，直到t1执行完毕后继续。
                    thread.join();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
        }
    }
}
 
class JoinDemo implements Runnable {
    @Override
    public void run() {
        for (int i = 0; i < 10; i++) {
            System.out.println("线程1第" + i + "次执行！");
        }
    }
}

运行结果如下图所示：
在这里插入图片描述
yield()
yield()方法和sleep()方法类似，也不会释放“锁标志”，区别在于，它没有参数，即yield()方法只是使当前线程重新回到可执行状态，所以执行yield()的线程有可能在进入到可执行状态后马上又被执行，另外yield()方法只能使同优先级或者高优先级的线程得到执行机会，这也和sleep()方法不同。

使当前线程从Running执行状态（运行状态）变为Runnable可执行态（就绪状态）。
Java线程中有一个Thread.yield( )方法，很多人翻译成线程让步。顾名思义，就是说当一个线程使用了这个方法之后，它就会把自己CPU执行的时间让掉，让自己或者其它的线程运行。
打个比方：现在有很多人在排队上厕所，好不容易轮到这个人上厕所了，突然这个人说：“我要和大家抢，看谁先抢到厕所！”，然后所有的人在同一起跑线冲向厕所，有可能是别人抢到了，也有可能他自己有抢到了。我们还知道线程有个优先级的问题，那么手里有优先权的这些人就一定能抢到厕所的位置吗? 不一定的，他们只是概率上大些，也有可能没特权的抢到了。

当线程调用了yeild()方法，意思是放弃当前获得的CPU时间片，回到可运行状态，这时与其他进程处于同等竞争状态，OS有可能会接着又让这个进程进入运行状态。

多线程的执行流程：多个线程并发请求执行时，由CPU决定优先执行哪一个，即使通过thread.setPriority()，设置了线程的优先级，也不一定就是每次都先执行它。yield，表示暂停当前线程，执行其他线程(包括自身线程) 由CPU决定。
测试代码如下所示：

public class TestYield implements Runnable {  
            public void run() {  
                System.out.println("first: " + Thread.currentThread().getName() );  
            // 暂停当前正在执行的线程对象，并执行其他线程，就是进入就绪状态  
 
                Thread.currentThread().yield();  
            // 可能还会执行 本线程: 以下语句不一定紧接着上面的语句被执行，可能其他线程的先执行了
                System.out.println("second: " + Thread.currentThread().getName() );  
        }  
 
            public static void main(String[] args) {  
 
            TestYield runn = new TestYield();  
 
            Thread thread1 = new Thread(runn,"thread1");
        	Thread thread2 = new Thread(runn,"thread2");
        	Thread thread3 = new Thread(runn,"thread3");
 
            t2.setPriority(t2.getPriority()+1); //设置t2的线程优先级
            t1.start();  
            t2.start();  
            t3.start();        
 
        }  
}

执行结果：

first:thread1
first:thread2
first:thread3
second:thread2
second:thread3
second:thread1

wait()
wait()方法需要和notify()及notifyAll()两个方法一起介绍，这三个方法用于协调多个线程对共享数据的存取，所以必须在synchronized语句块内使用，也就是说，调用wait()，notify()和notifyAll()的任务在调用这些方法前必须拥有对象的锁。注意，它们都是Object类的方法，而不是Thread类的方法。

wait()方法与sleep()方法的不同之处在于，wait()方法会释放对象的“锁标志”。当调用某一对象的wait()方法后，会使当前线程暂停执行，并将当前线程放入对象等待池中，直到调用了notify()方法后，将从对象等待池中移出任意一个线程并放入锁标志等待池中，只有锁标志等待池中的线程可以获取锁标志，它们随时准备争夺锁的拥有权。当调用了某个对象的notifyAll()方法，会将对象等待池中的所有线程都移动到该对象的锁标志等待池。

除了使用notify()和notifyAll()方法，还可以使用带毫秒参数的wait(long timeout)方法，效果是在延迟timeout毫秒后，被暂停的线程将被恢复到锁标志等待池。

此外，wait()，notify()及notifyAll()只能在synchronized语句中使用，但是如果使用的是ReenTrantLock实现同步，该如何达到这三个方法的效果呢？解决方法是使用ReenTrantLock.newCondition()获取一个Condition类对象，然后Condition的await()，signal()以及signalAll()分别对应上面的三个方法。
　
sleep()
sleep()方法需要指定等待的时间，它可以让当前正在执行的线程在指定的时间内暂停执行，进入阻塞状态，该方法既可以让其他同优先级或者高优先级的线程得到执行的机会，也可以让低优先级的线程得到执行机会。但是sleep()方法不会释放“锁标志”，也就是说如果有synchronized同步块，其他线程仍然不能访问共享数据。

1.sleep()方法会给其他线程运行的机会，而不考虑其他线程的优先级，因此会给较低线程一个运行的机会；yield()方法只会给相同优先级或者更高优先级的线程一个运行的机会。
2.当线程执行了sleep(long millis)方法后，将转到阻塞状态，参数millis指定睡眠时间；当线程执行了yield()方法后，将转到就绪状态。
3.sleep()方法声明抛出InterruptedException异常，而yield()方法没有声明抛出任何异常。
4.sleep()方法比yield()方法具有更好的移植性。
5.当线程调用了自身的sleep()方法或其他线程的join()方法，就会进入阻塞状态(该状态既停止当前线程，但并不释放所占有的资源)。当sleep()结束或join()结束后，该线程进入可运行状态，继续等待os分配时间片。

11.线程的调度策略
线程调度器选择优先级最高的线程运行，但是，如果发生以下情况，就会终止线程的运行：
1）线程体中调用了yield方法让出了对cpu的占用权利
2）线程体中调用了sleep方法使线程进入睡眠状态
3）线程由于IO操作受到阻塞
4）另外一个更高优先级线程出现
5）在支持时间片的系统中，该线程的时间片用完

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

13.什么是线程调度器(Thread Scheduler)和时间分片(Time Slicing)？
线程调度器是一个操作系统服务，它负责为Runnable状态的线程分配CPU时间。一旦我们创建一个线程并启动它，它的执行便依赖于线程调度器的实现。时间分片是指将可用的CPU时间分配给可用的Runnable线程的过程。分配CPU时间可以基于线程优先级或者线程等待的时间。线程调度并不受到Java虚拟机控制，所以由应用程序来控制它是更好的选择（也就是说不要让你的程序依赖于线程的优先级）。

14.Java线程数过多会造成什么异常？
1）线程的生命周期开销非常高
2）消耗过多的CPU资源
如果可运行的线程数量多于可用处理器的数量，那么有线程将会被闲置。大量空闲的线程会占用许多内存，给垃圾回收器带来压力，而且大量的线程在竞争CPU资源时还将产生其他性能的开销。
3）降低稳定性
JVM在可创建线程的数量上存在一个限制，这个限制值将随着平台的不同而不同，并且承受着多个因素制约，包括JVM的启动参数、Thread构造函数中请求栈的大小，以及底层操作系统对线程的限制等。如果破坏了这些限制，那么可能抛出OutOfMemoryError异常。

15、线程类的构造方法、静态块是被哪个线程调用的

这是一个非常刁钻和狡猾的问题。请记住：线程类的构造方法、静态块是被new这个线程类所在的线程所调用的，而run方法里面的代码才是被线程自身所调用的。
如果说上面的说法让你感到困惑，那么我举个例子，假设Thread2中new了Thread1，main函数中new了Thread2，那么：
1）Thread2的构造方法、静态块是main线程调用的，Thread2的run()方法是Thread2自己调用的
2）Thread1的构造方法、静态块是Thread2调用的，Thread1的run()方法是Thread1自己调用的

关于线程池的几连击：
8、线程池的优点？
为什么要用线程池 ？
线程池提供了一种限制和管理资源（包括执行一个任务）。每个线程池还维护一些基本统计信息，例如已完成任务的数量。
使用线程池的好处：

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

9、什么是线程池？有哪几种创建方式？
线程池就是提前创建若干个线程，如果有任务需要处理，线程池里的线程就会处理任务，处理完之后线程并不会被销毁，而是等待下一个任务。由于创建和销毁线程都是消耗系统资源的，所以当你想要频繁的创建和销毁线程的时候就可以考虑使用线程池来提升系统的性能。
如何创建线程池：

方式一：通过构造方法实现
在这里插入图片描述
方式二：通过Executor 框架的工具类Executors来实现
对应Executors工具类中的方法如图所示：

java 提供了一个 java.util.concurrent.Executor接口的实现用于创建线程池。
Java通过Executors类提供四种线程池，分别为：
newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

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

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

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

1).newCachedThreadPool 这里的线程池是无限大的，当一个线程完成任务之后，这个线程可以接下来完成将要分配的任务，而不是创建一个新的线程。

public static void main(String[] args) {  
        ExecutorService cachedThreadPool = Executors.newCachedThreadPool();  
        for (int i = 0; i < 10; i++) {  
            final int index = i;  
            try {  
                Thread.sleep(10);  
            } catch (InterruptedException e) {  
                e.printStackTrace();  
            }  
            cachedThreadPool.execute(new Runnable() {  
                public void run() {  
                    System.out.println(index);  
                }  
            });  
        }  
    }

2).newFixedThreadPool

public static void main(String[] args) {  
        ExecutorService fixedThreadPool = Executors.newFixedThreadPool(3);  
        for (int i = 0; i < 10; i++) {  
            final int index = i;  
            fixedThreadPool.execute(new Runnable() {  
                public void run() {  
                    try {  
                        System.out.println(index);  
                        Thread.sleep(10);  
                    } catch (InterruptedException e) {  
                        e.printStackTrace();  
                    }  
                }  
            });  
        }  
    }

3).newScheduledThreadPool

public static void main(String[] args) {  
        ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(5);  
        for (int i = 0; i < 10; i++) {  
            scheduledThreadPool.schedule(new Runnable() {  
                public void run() {  
                    System.out.println("delay 3 seconds");  
                }  
            }, 3, TimeUnit.SECONDS);  
        }  
  
    }

4).newSingleThreadExecutor 按顺序来执行线程任务但是不同于单线程，这个线程池只是只能存在一个线程，这个线程死后另外一个线程会补上。

public static void main(String[] args) {  
        ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();  
        for (int i = 0; i < 10; i++) {  
            final int index = i;  
            singleThreadExecutor.execute(new Runnable() {  
                public void run() {  
/*                  System.out.println(index);*/  
                    try {  
                        System.out.println(index);  
                        Thread.sleep(2000);  
                    } catch (InterruptedException e) {  
                        e.printStackTrace();  
                    }  
                }  
            });  
        }  
    }

《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，使用Executors创建线程池可能会导致OOM(OutOfMemory ,内存溢出)，而是通过ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
在这里插入图片描述
先来一个简单的例子，模拟一下使用Executors导致OOM的情况：

public class ExecutorsDemo {
    private static ExecutorService executor = Executors.newFixedThreadPool(15);
    public static void main(String[] args) {
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            executor.execute(new SubThread());
        }
    }
}
 
class SubThread implements Runnable {
    @Override
    public void run() {
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
            //do nothing
        }
    }
}

通过指定JVM参数：-Xmx8m -Xms8m(最大堆和最小堆) 运行以上代码，会抛出OOM:
在这里插入图片描述
以上代码指出，ExecutorsDemo.java的第16行，就是代码中的executor.execute(new SubThread());。
其实，在上面的报错信息中，我们是可以看出在以上的代码中其实已经说了，真正的导致OOM的其实是LinkedBlockingQueue.offer方法。翻看代码的话，也可以发现，其实底层确实是通过LinkedBlockingQueue实现的

public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());

Java中的BlockingQueue主要有两种实现，
分别是ArrayBlockingQueue 和LinkedBlockingQueue。
ArrayBlockingQueue是一个用数组实现的有界阻塞队列，必须设置容量。
LinkedBlockingQueue是一个用链表实现的有界阻塞队列，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。
这里的问题就出在：不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。也就是说，如果我们不设置LinkedBlockingQueue的容量的话，其默认容量将会是Integer.MAX_VALUE。
而newFixedThreadPool中创建LinkedBlockingQueue时，并未指定容量。此时，LinkedBlockingQueue就是一个无边界队列，对于一个无边界队列来说，是可以不断的向队列中加入任务的，这种情况下就有可能因为任务过多而导致内存溢出问题。

上面提到的问题主要体现在newFixedThreadPool和newSingleThreadExecutor两个工厂方法上，并不是说newCachedThreadPool和newScheduledThreadPool这两个方法就安全了，这两种方式创建的最大线程数可能是Integer.MAX_VALUE，而创建这么多线程，必然就有可能导致OOM。

创建线程池的正确姿势
避免使用Executors创建线程池，主要是避免使用其中的默认实现，那么我们可以自己直接调用ThreadPoolExecutor的构造函数来自己创建线程池。在创建的同时，给BlockQueue指定容量就可以了。

private static ExecutorService executor = new ThreadPoolExecutor(10, 10,
        60L, TimeUnit.SECONDS,
        new ArrayBlockingQueue(10));

这种情况下，一旦提交的线程数超过当前可用线程数时，就会抛出java.util.concurrent.RejectedExecutionException，这是因为当前线程池使用的队列是有边界队列，队列已经满了便无法继续处理新的请求。但是异常（Exception）总比发生错误（Error）要好。

Executors类是什么？
Executors为Executor，ExecutorService，ScheduledExecutorService，ThreadFactory和Callable类提供了一些工具方法。
Executors可以用于方便的创建线程池

Executor vs ExecutorService vs Executors
这三者均是 Executor 框架中的一部分。总结一下这三者间的区别：

Executor 和 ExecutorService 这两个接口主要的区别是：ExecutorService 接口继承了 Executor接口，是 Executor 的子接口
Executor 和 ExecutorService 第二个区别是：Executor 接口定义了execute()方法用来接收一个Runnable接口的对象，而 ExecutorService 接口中的submit()方法可以接受Runnable和Callable接口的对象。
Executor 和 ExecutorService 接口第三个区别是 Executor 中的 execute() 方法不返回任何结果，而ExecutorService 中的 submit()方法可以通过一个 Future 对象返回运算结果。
Executor 和 ExecutorService 接口第四个区别是除了允许客户端提交一个任务，ExecutorService还提供用来控制线程池的方法。比如：调用 shutDown() 方法终止线程池。
Executors 类提供工厂方法用来创建不同类型的线程池。比如:newSingleThreadExecutor()创建一个只有一个线程的线程池，newFixedThreadPool(int numOfThreads)来创建固定线程数的线程池，newCachedThreadPool()可以根据需要创建新的线程，但如果已有线程是空闲的会重用已有线程。

Executor 接口对象能执行我们的线程任务；
Executors 工具类的不同方法按照我们的需求创建了不同的线程池，来满足业务的需求。
ExecutorService 接口继承了Executor接口并进行了扩展，提供了更多的方法，我们能够获得任务执行的状态并且可以获取任务的返回值。
在这里插入图片描述
10、线程池中实现Runnable接口和Callable接口的区别
如果想让线程池执行任务的话需要实现的Runnable接口或Callable接口。 Runnable接口或Callable接口实现类都可以被ThreadPoolExecutor或ScheduledThreadPoolExecutor执行。两者的区别在于 Runnable 接口不会返回结果但是 Callable 接口可以返回结果。
备注：工具类 Executors 可以实现 Runnable 对象和 Callable 对象之间的相互转换。（ Executors.callable（Runnable task）或 Executors.callable（Runnable task，Object resule））。
通过实现Runnable接口的实现

package Thread;
 
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
 
public class RunnableThreadDemo {
 
	private static int POOL_NUM = 30; // 线程池数量
 
	public static void main(String[] args) throws InterruptedException {
		ExecutorService executorService = Executors.newFixedThreadPool(10);
		for (int i = 0; i < POOL_NUM; i++) {
			RunnableThread thread = new RunnableThread();
			//线程停顿
			Thread.sleep(1000);
			executorService.execute(thread);
		}
		// 关闭线程池
		executorService.shutdown();
	}
 
}
 
class RunnableThread implements Runnable {
	@Override
	public void run() {
		System.out.println("通过线程池方式创建的线程Runnable方式：" + Thread.currentThread().getName() + " ");
	}
}

通过实现Callable接口的实现

package Thread;
 
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.FutureTask;
 
 
public class CallableThreadDemo {
 
	private static int POOL_NUM = 30; // 线程池数量
 
	public static void main(String[] args) throws InterruptedException, ExecutionException {
		ExecutorService executorService = Executors.newFixedThreadPool(10);
		for (int i = 0; i < POOL_NUM; i++) {
			Callable<Integer> callableThread = new CallableThread();
 
			FutureTask<Integer> thread = new FutureTask<Integer>(callableThread);
			//线程停顿
			Thread.sleep(1000); 
			//执行 Callable 方式，需要 FutureTask 实现类的支持，用于接收运算结果。  FutureTask 是  Future 接口的实现类
			executorService.submit(thread);
 
			System.out.println(thread.get());
		}
		// 关闭线程池
		executorService.shutdown();
	}
}
 
class CallableThread implements Callable<Integer> {
 
	@Override
	public Integer call() throws Exception {
		System.out.println("通过线程池方式创建的线程Callable方式：" + Thread.currentThread().getName() + " ");
		return 10086;
	}
}

区别：
1.Callable规定的方法是call()，而Runnable规定的方法是run().
2.Callable的任务执行后可返回值，而Runnable的任务是不能返回值的。
3.call() 方法可抛出异常，而run() 方法是不能抛出异常的。
4.运行Callable任务可拿到一个Future对象， Future表示异步计算的结果。
5.它提供了检查计算是否完成的方法，以等待计算的完成，并检索计算的结果。
6.通过Future对象可了解任务执行情况，可取消任务的执行，还可获取任务执行的结果。
7.Callable是类似于Runnable的接口，实现Callable接口的类和实现Runnable的类都是可被其它线程执行的任务。

（ ExecutorService、Callable都是属于Executor框架。返回结果的线程是在JDK1.5中引入的新特征，还有Future接口也是属于这个框架，有了这种特征得到返回值就很方便了。）

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

execute() 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否（execute()方法只有实现了Runnable的类才能使用）；
2)submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用 get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。

12.如果你提交任务时，线程池队列已满，这时会发生什么
这里区分一下：

1）如果使用的是无界队列LinkedBlockingQueue，也就是无界队列的话，没关系，继续添加任务到阻塞队列中等待执行，因为LinkedBlockingQueue可以近乎认为是一个无穷大的队列，可以无限存放任务
2）如果使用的是有界队列比如ArrayBlockingQueue，任务首先会被添加到ArrayBlockingQueue中，ArrayBlockingQueue满了，会根据maximumPoolSize的值增加线程数量，如果增加了线程数量还是处理不过来，ArrayBlockingQueue继续满，那么则会使用拒绝策略RejectedExecutionHandler处理满了的任务，默认是AbortPolicy

13、常用的并发工具类有哪些？
CountDownLatch
CyclicBarrier
Semaphore
Exchanger

14、CyclicBarrier和CountDownLatch的区别

1）CountDownLatch简单的说就是一个线程等待，直到他所等待的其他线程都执行完成并且调用countDown()方法发出通知后，当前线程才可以继续执行。

2）cyclicBarrier是所有线程都进行等待，直到所有线程都准备好进入await()方法之后，所有线程同时开始执行！

3）CountDownLatch的计数器只能使用一次。而CyclicBarrier的计数器可以使用reset() 方法重置。所以CyclicBarrier能处理更为复杂的业务场景，比如如果计算发生错误，可以重置计数器，并让线程们重新执行一次。

4）CyclicBarrier还提供其他有用的方法，比如getNumberWaiting方法可以获得CyclicBarrier阻塞的线程数量。isBroken方法用来知道阻塞的线程是否被中断。如果被中断返回true，否则返回false。

15、实现可见性的方法有哪些？
synchronized或者Lock：保证同一个时刻只有一个线程获取锁执行代码，锁释放之前把最新的值刷新到主内存，实现可见性。

16.多线程同步有哪几种方法？
Synchronized关键字，Lock锁实现，分布式锁等。
（要说明线程同步问题首先要说明Java线程的两个特性：可见性和有序性）

一、面试中关于 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 方法一样，synchronized(this)代码块也是锁定当前对象的。synchronized 关键字加到 static 静态方法和synchronized(class)代码块上都是是给 Class 类上锁。这里再提一下：synchronized关键字加到非static 静态方法上是给对象实例上锁。另外需要注意的是：尽量不要使用 synchronized(String a)因为JVM中，字符串常量池具有缓冲功能！

同步方法和同步块，哪个是更好的选择?
同步块，这意味着同步块之外的代码是异步执行的，这比同步整个方法更提升代码的效率。请知道一条原则：同步的范围越小越好。

下面我已一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。
面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！”

这里先说一下单例模式的线程安全性
老生常谈的问题了，首先要说的是单例模式的线程安全意味着：某个类的实例在多线程环境下只会被创建一次出来。单例模式有很多种的写法，总结一下：
1）饿汉式单例模式的写法：线程安全
2）懒汉式单例模式的写法：非线程安全
3）双检锁单例模式的写法：线程安全

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

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

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

但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

上面是懒汉模式下双重校验锁下的简单代码，下面看一下懒汉模式下非双重校验锁下的简单代码：

public class Singleton {
    private volatile static Singleton uniqueInstance;
    private Singleton() {
    }
    public static Singleton getUniqueInstance() {
        if (uniqueInstance == null) {
            synchronized (Singleton.class) {//如果是非线程安全就没有synchronized修饰了   
                    uniqueInstance = new Singleton();        
            }
        }
        return uniqueInstance;
    }
}

差别在于第二个if判断能拦截第一个获得对象锁线程以外的线程。
在这里插入图片描述
下面是最普通的单例模式，这个是懒汉式，线程不安全:

//这个是普通的单例模式
public class Singleton{
	private static Singleton instance = null;
	private Singleton(){
	}
	public static Singleton getInstance(){
		if (instance == null) {
			instance = new Singleton();
		}
		return instance;
	}
}

静态内部类 stat nested class

public class Singleton {
    private static class SingletonInner{
        private static final Singleton INSTANCE = new Singleton();
    }
    private Singleton(){
    }
    private static final Singleton getInstance(){
        return SingletonInner.INSTANCE;
    }
}

这种写法仍然使用JVM本身机制保证了线程安全问题；由于 SingletonInner是私有的，除了 getInstance() 之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本。

上述种都是懒汉式实现的单例，下面说一下饿汉式：
饿汉模式 static final field 这种方法也是很简单，只需要将单例的实例声明为static和final变量。这是因为在第一次加载到内存中的就会被初始化，所以创建实例本身是线程安全的。

public class Singleton{
    //类加载时就初始化
    private static final Singleton instance = new Singleton();
    
    private Singleton(){}
    public static Singleton getInstance(){
        return instance;
    }
}

这种写法如果完美的话，就没必要在啰嗦那么多双检锁的问题了。缺点是它不是一种懒加载模式（lazy initialization），单例会在加载类后一开始就被初始化，即使客户端没有调用 getInstance()方法。饿汉式的创建方式在一些场景中将无法使用：譬如 Singleton 实例的创建是依赖参数或者配置文件的,在 getInstance()之前必须调用某个方法设置参数给它,那样这种单例写法就无法使用了

还有一种是枚举法：
枚举 Enum
用枚举写单例实在太简单了！这也是它最大的优点。下面这段代码就是声明枚举实例的通常做法。

public enum EasySingleton{
    INSTANCE;
}

我们可以通过EasySingleton.INSTANCE来访问实例，这比调用getInstance()方法简单多了。创建枚举默认就是线程安全的，所以不需要担心double checked locking，而且还能防止反序列化导致重新创建新的对象。但是还是很少看到有人这样写，可能是因为不太熟悉吧。
总结
一般来说，单例模式有五种写法：懒汉、饿汉、双重检验锁、静态内部类、枚举。上述所说都是线程安全的实现，第三种方法不算正确的写法。
一般情况下直接使用饿汉式就好了，如果明确要求要懒加载（lazy initialization）会倾向于使用静态内部类，如果涉及到反序列化创建对象时会试着使用枚举的方式来实现单例。

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 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。
锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

①偏向锁
引入偏向锁的目的和引入轻量级锁的目的很像，他们都是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。但是不同是：轻量级锁在无竞争的情况下使用 CAS 操作去代替使用互斥量。而偏向锁在无竞争的情况下会把整个同步都消除掉。
偏向锁的“偏”就是偏心的偏，它的意思是会偏向于第一个获得它的线程，如果在接下来的执行中，该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步！
但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。

② 轻量级锁
倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)。轻量级锁不是为了代替重量级锁，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗，因为使用轻量级锁时，不需要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操作。
轻量级锁能够提升程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥操作的开销。但如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因此在有锁竞争的情况下，轻量级锁比传统的重量级锁更慢！如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁！

③ 自旋锁和自适应自旋
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。
互斥同步对性能最大的影响就是阻塞的实现，因为挂起线程/恢复线程的操作都需要转入内核态中完成（用户态转换到内核态会耗费时间）。
一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。所以，虚拟机的开发团队就这样去考虑：“我们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。为了让一个线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就叫做自旋。
百度百科对自旋锁的解释：
在这里插入图片描述
自旋锁在 JDK1.6 之前其实就已经引入了，不过是默认关闭的，需要通过–XX:+UseSpinning参数来开启。JDK1.6及1.6之后，就改为默认开启的了。需要注意的是：自旋等待不能完全替代阻塞，因为它还是要占用处理器时间。如果锁被占用的时间短，那么效果当然就很好了！反之，相反！自旋等待的时间必须要有限度。如果自旋超过了限定次数仍然没有获得锁，就应该挂起线程。自旋次数的默认值是10次，用户可以修改 --XX:PreBlockSpin来更改。
另外,在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得越来越“聪明”了。
④ 锁消除
锁消除理解起来很简单，它指的就是虚拟机即使编译器在运行时，如果检测到那些共享数据不可能存在竞争，那么就执行锁消除。锁消除可以节省毫无意义的请求锁的时间。
⑤ 锁粗化
原则上，我们再编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待线程也能尽快拿到锁。
大部分情况下，上面的原则都是没有问题的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗。
锁粗化就是告诉我们任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。

1.5) 什么是CAS
说CAS之前先举一个例子：
启动两个线程，每个线程中让静态变量count循环累加100次。
在这里插入图片描述
最终输出的count结果一定是200吗？因为这段代码是非线程安全的，所以最终的自增结果很可能会小于200。我们再加上synchronized同步锁，再来看一下。

加了同步锁之后，count自增的操作变成了原子性操作，所以最终输出一定是count=200，代码实现了线程安全。虽然synchronized确保了线程安全，但是在某些情况下，这并不是一个最有的选择。
关键在于性能问题：
synchronized关键字会让没有得到锁资源的线程进入BLOCKED状态，而后在争夺到锁资源后恢复为RUNNABLE状态，这个过程中涉及到操作系统用户模式和内核模式的转换，代价比较高。
尽管JAVA 1.6为synchronized做了优化，增加了从偏向锁到轻量级锁再到重量级锁的过过度，但是在最终转变为重量级锁之后，性能仍然比较低。所以面对这种情况，我们就可以使用java中的“原子操作类”。

所谓原子操作类，指的是java.util.concurrent.atomic包下，一系列以Atomic开头的包装类。如AtomicBoolean，AtomicUInteger，AtomicLong。它们分别用于Boolean，Integer，Long类型的原子性操作。

现在我们尝试使用AtomicInteger类：
在这里插入图片描述
使用AtomicInteger之后，最终的输出结果同样可以保证是200。并且在某些情况下，代码的性能会比synchronized更好。
而Atomic操作类的底层正是用到了“CAS机制”。

CAS是英文单词Compare and Swap的缩写，翻译过来就是比较并替换。
cas是一种基于锁的操作，而且是乐观锁。在java中锁分为乐观锁和悲观锁。悲观锁是将资源锁住，等一个之前获得锁的线程释放锁之后，下一个线程才可以访问。而乐观锁采取了一种宽泛的态度，通过某种方式不加锁来处理资源，比如通过给记录加version来获取数据，性能较悲观锁有很大的提高。

CAS 操作包含三个操作数 —— 内存位置（V）、旧的预期值（A），要修改的新值（B）。如果内存地址V里面的值旧的预期值A的值是一样的，那么就将内存里面的值更新成B。CAS是通过无限循环来获取数据的，如果在第一轮循环中，a线程获取地址里面的值被b线程修改了，那么a线程需要自旋，到下次循环才有可能机会执行。

java.util.concurrent.atomic 包下的类大多是使用CAS操作来实现的( AtomicInteger,AtomicBoolean,AtomicLong)。
例如AtomicInteger的用法如下：

 AtomicInteger atomicInteger=new AtomicInteger(0);
 int i=atomicInteger.get();
 atomicInteger.compareAndSet(i,i++);

我们看一个例子：

在内存地址V当中，存储着值为10的变量。
此时线程1想把变量的值增加1.对线程1来说，旧的预期值A=10，要修改的新值B=11.
在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11。
线程1开始提交更新，首先进行A和地址V的实际值比较，发现A不等于V的实际值，提交失败。
线程1 重新获取内存地址V的当前值，并重新计算想要修改的值。此时对线程1来说，A=11，B=12。这个重新尝试的过程被称为自旋。
这一次比较幸运，没有其他线程改变地址V的值。线程1进行比较，发现A和地址V的实际值是相等的。
线程1进行交换，把地址V的值替换为B，也就是12.

从思想上来说，synchronized属于悲观锁，悲观的认为程序中的并发情况严重，所以严防死守，CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去重试更新。
在java中除了上面提到的Atomic系列类，以及Lock系列类夺得底层实现，甚至在JAVA1.6以上版本，synchronized转变为重量级锁之前，也会采用CAS机制。

1.6) CAS的问题/缺点
1） CPU开销过大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很到的压力。

2）不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用synchronized了。

3） CAS容易造成ABA问题
一个线程a将数值改成了b，接着又改成了a，此时CAS认为是没有变化，其实是已经变化过了，而这个问题的解决方案可以使用版本号标识，每操作一次version加1（那么A——B——A 就变成了1A——2B——3A）。在java5中，已经提供了AtomicStampedReference来解决问题。

1.7）JAVA中CAS的底层实现
首先看一下看一下AtomicInteger当中常用的自增方法incrementAndGet：

public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}
private volatile int value; 
public final int get() {
    return value;
}

这段代码是一个无限循环，也就是CAS的自旋，循环体中做了三件事：

获取当前值
当前值+1，计算出目标值
进行CAS操作，如果成功则跳出循环，如果失败则重复上述步骤
这里需要注意的重点是get方法，这个方法的作用是获取变量的当前值。
如何保证获取的当前值是内存中的最新值？很简单，用volatile关键字来保证（保证线程间的可见性）。我们接下来看一下compareAndSet方法的实现：

compareAndSet方法的实现很简单，只有一行代码。这里涉及到两个重要的对象，一个是unsafe，一个是valueOffset。
什么是unsafe呢？Java语言不像C，C++那样可以直接访问底层操作系统，但是JVM为我们提供了一个后门，这个后门就是unsafe。unsafe为我们提供了硬件级别的原子操作。
至于valueOffset对象，是通过unsafe.objectFiledOffset方法得到，所代表的是AtomicInteger对象value成员变量在内存中的偏移量。我们可以简单的把valueOffset理解为value变量的内存地址。
我们上面说过，CAS机制中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。
而unsafe的compareAndSwapInt方法的参数包括了这三个基本元素：valueOffset参数代表了V，expect参数代表了A，update参数代表了B。
正是unsafe的compareAndSwapInt方法保证了Compare和Swap操作之间的原子性操作。

1.8）CAS的ABA问题和解决办法
我们现在来说什么是ABA问题。假设内存中有一个值为A的变量，存储在地址V中。
在这里插入图片描述
此时有三个线程想使用CAS的方式更新这个变量的值，每个线程的执行时间有略微偏差。线程1和线程2已经获取当前值，线程3还未获取当前值。

接下来，线程1先一步执行成功，把当前值成功从A更新为B；同时线程2因为某种原因被阻塞住，没有做更新操作；线程3在线程1更新之后，获取了当前值B。
在这里插入图片描述
在之后，线程2仍然处于阻塞状态，线程3继续执行，成功把当前值从B更新成了A。

最后，线程2终于恢复了运行状态，由于阻塞之前已经获得了“当前值A”，并且经过compare检测，内存地址V中的实际值也是A，所以成功把变量值A更新成了B。
在这里插入图片描述
看起来这个例子没啥问题，但如果结合实际，就可以发现它的问题所在。
我们假设一个提款机的例子。假设有一个遵循CAS原理的提款机，小灰有100元存款，要用这个提款机来提款50元。

由于提款机硬件出了点问题，小灰的提款操作被同时提交了两次，开启了两个线程，两个线程都是获取当前值100元，要更新成50元。
理想情况下，应该一个线程更新成功，一个线程更新失败，小灰的存款值被扣一次。
在这里插入图片描述
线程1首先执行成功，把余额从100改成50.线程2因为某种原因阻塞。这时，小灰的妈妈刚好给小灰汇款50元。

线程2仍然是阻塞状态，线程3执行成功，把余额从50改成了100。

线程2恢复运行，由于阻塞之前获得了“当前值”100，并且经过compare检测，此时存款实际值也是100，所以会成功把变量值100更新成50。
在这里插入图片描述
原本线程2应当提交失败，小灰的正确余额应该保持100元，结果由于ABA问题提交成功了。
怎么解决呢？加个版本号就可以了。
真正要做到严谨的CAS机制，我们在compare阶段不仅要比较期望值A和地址V中的实际值，还要比较变量的版本号是否一致。
我们仍然以刚才的例子来说明，假设地址V中存储着变量值A，当前版本号是01。线程1获取了当前值A和版本号01，想要更新为B，但是被阻塞了。
在这里插入图片描述
这时候，内存地址V中变量发生了多次改变，版本号提升为03，但是变量值仍然是A。

随后线程1恢复运行，进行compare操作。经过比较，线程1所获得的值和地址的实际值都是A，但是版本号不相等，所以这一次更新失败。
在这里插入图片描述
在Java中，AtomicStampedReference类就实现了用版本号作比较额CAS机制。

1.9) 什么是乐观锁和悲观锁
1）乐观锁：就像它的名字一样，对于并发间操作产生的线程安全问题持乐观状态，乐观锁认为竞争不总是会发生，因此它不需要持有锁，将比较-替换这两个动作作为一个原子操作尝试去修改内存中的变量，如果失败则表示发生冲突，那么就应该有相应的重试逻辑。

2）悲观锁：还是像它的名字一样，对于并发间操作产生的线程安全问题持悲观状态，悲观锁认为竞争总是会发生，因此每次对某资源进行操作时，都会持有一个独占的锁，就像synchronized，不管三七二十一，直接上了锁就操作资源了。

2.0）synchronized、volatile、CAS比较
synchronized是悲观锁，属于抢占式，会引起其他线程阻塞。
volatile提供多线程共享变量可见性和禁止指令重排序优化。
CAS是基于冲突检测的乐观锁（非阻塞）

二、面试中关于 lock的几连击
Lock锁:对需要上锁的地方上锁

JDK1.5后新增的功能
2)与Synchronized相比，Lock 可提供多种锁方案，更灵活
Java.util.concurrent.lock 中的Lock是一个接口，它的实现类是一个Java类，而不是作为语言的特性(关键字)来实现
注意:如果同步代码有异常，要将unLock()放到finally 中

使用步骤
1)创建Lock对象
2)调用lock()方法上锁
3)调用unlock()方法解锁

Lock有ReadLock、WriteLock、ReentrantLock（可重入锁）
常用的就是ReentrantLock。
（ ReentrantLock锁具有可重入性可以对已被加锁的ReentrantLock锁再次加锁，线程每次调用lock()加锁后，必须显示的调用unlock来释放锁，有几个lock就对应几个unlock。还有把unlock放在finally代码块中，Lock在发生异常时也是不释放锁的，所以在finally中释放更安全。）

Jdk5新增了Lock接口以及他的一个实现类ReentrantLock（重入锁），以及ReadWriteLock接口和他的唯一实现类ReentrantReadWriteLock.这个类有两个锁，一个是读操作锁，一个是写操作锁。使用读操作锁时可以允许多个线程同时访问，使用写操作锁时只允许一个线程进行。在一个线程执行写操作时，其他线程不能够执行读操作。Lock也可以用来实现多线程的同步，具体而言，他提供了如下一些方法来实现多线程的同步：

lock()。以阻塞方式来获取锁，如果获取到了锁，立即返回；如果别的线程持有锁，则当前线程等待，直到获取锁后返回。
tryLock()。以非阻塞的方式获取锁。只是尝试性的去获取一下锁，如果获取到锁，立即返回true，立即否则返回false。
tryLock(longtimeout,TimeUnit unit)。如果获取到了锁，立即返回true，否则会等待参数给定的时间单元，在等待的过程中，如果获取到了锁，就立即返回true。如果等待超时，返回false。
lockInterruptibly（）。如果获取到了锁，立即返回；如果没有获取到锁，当前线程处于休眠状态，或者当前线程会被别的线程中断（会受到InterruptedException异常）。他与lock()方法的区别在于lock优先考虑获取锁，如果没有获取到锁，会一直处于阻塞状态，忽略interrupt（）方法，待获取锁成功后，才响应中断。lockInterruptibly 优先考虑响应中断，而不是响应锁的普通获取或重入获取。
ReentrantLock()。创建一个ReentrantLock实例。
Unlock()。释放锁

ReentrantLock是基于AQS而设计的AQS全称AbstractQueuedSynchronizer，中文名抽象队列同步器，是并发包JUC中最基本的组件，JUC包中大部分类都基于它实现的并发处理故其为一个抽象类，使用AQS需要去继承该类并重写其被protected修饰的几个方法。AQS内部实现了一个FIFO队列，队列中的节点维护了当先线程的引用及其状态，每个线程都可以视为AQS中的一个节点，AQS中节点的定义如下：
在这里插入图片描述
既然是队列其实现无非就是数组或者链表，在AQS中实现为双向队列，其中prev为节点的前驱，next为节点的后驱，thread为当前线程，nextWaiter为存储condition队列中的后继节点，waitStatus为节点等待状态，主要有以下几种状态：

waitStatus=1，线程被取消

waitStatus=2，线程正在等待一个condition。

waitStatus=-1，表示当前节点的后继节点包含的线程需要运行，也就是unpark。

waitStatus=3，表示当前场景下后续的acquireShared能够得以执行。

waitStatus=0，表示当前节点在sync队列中，等待着获取锁。

前面讲到了可重入锁，可重入锁就是当前持有该锁的线程能够多次获取该锁，无需等待。下面介绍一下可重入锁。举个例子：村里面有一口井，村民都想到井里面打水，村里人太多，要制定一个打水的规则。井边安排一个看井人，维护打水的秩序。打水时，以家庭为单位，哪个家庭任何人先到井边，就可以先打水，而且如果一个家庭占到了打水权，其家人这时候过来打水不用排队。而那些没有抢占到打水权的人，一个一个挨着在井边排成一队，先到的排在前面。打水示意图如下：
在这里插入图片描述
是不是感觉很和谐，如果打水的人打完了，他会跟看井人报告，看井人会让第二个人接着打水。这样大家总都能够打到水。是不是看起来挺公平的，先到的人先打水，当然不是绝对公平的，自己看看下面这个场景 :
在这里插入图片描述
看着，一个有娃的父亲正在打水，他的娃也到井边了，所以女凭父贵直接排到最前面打水，羡煞旁人了。

以上这个故事模型就是所谓的公平锁模型，当一个人想到井边打水，而现在打水的人又不是自家人，这时候就得乖乖在队列后面排队。

然而总有些人不想排队，新来打水的人，他们看到有人排队打水的时候，他们不会那么乖巧的就排到最后面去排队，反之，他们会看看现在有没有人正在打水，如果有人在打水，没辄了，只好排到队列最后面，但如果这时候前面打水的人刚刚打完水，正在交接中，排在队头的人还没有完成交接工作，这时候，新来的人可以尝试抢打水权，如果抢到了，呵呵，其他人也只能睁一只眼闭一只眼，因为大家都默认这个规则了。这就是所谓的非公平锁模型。新来的人不一定总得乖乖排队，这也就造成了原来队列中排队的人可能要等很久很久。这就是所谓的非公平锁模型。

ReentrantLock支持两种获取锁的方式，一种是公平模型，一种是非公平模型。我们先把故事元素转换为程序元素。
在这里插入图片描述
首先说说公平模型：初始化时，state=0，表示无人抢占了打水权。这时候，村民A来打水(A线程请求锁)，占了打水权，把state+1，如下所示：

线程A取得了锁，通过CAS s把tate原子性+1,这时候state被改为1，A线程继续执行其他任务，然后来了村民B也想打水（线程B请求锁），线程B无法获取锁，生成节点进行排队，如下图所示：
在这里插入图片描述
初始化的时候，会生成一个空的头节点，然后才是B线程节点，这时候，如果线程A又请求锁，是否需要排队？答案当然是否定的，否则就直接死锁了。当A再次请求锁，就相当于是打水期间，同一家人也来打水了，是有特权的，这时候的状态如下图所示：
在这里插入图片描述
这就可重入锁。就是一个线程在获取了锁之后，再次去获取了同一个锁，这时候仅仅是把状态值进行累加。如果线程A释放了一次锁，就成这样了：

仅仅是把状态值减了，只有线程A把此锁全部释放了，状态值减到0了，其他线程才有机会获取锁。当A把锁完全释放后，state恢复为0，然后会通知队列唤醒B线程节点，使B可以再次竞争锁。当然，如果B线程后面还有C线程，C线程继续休眠，除非B执行完了，通知了C线程。注意，当一个线程节点被唤醒然后取得了锁，对应节点会从队列中删除。

非公平锁模型：当线程A执行完之后，要唤醒线程B是需要时间的，而且线程B醒来后还要再次竞争锁，所以如果在切换过程当中，来了一个线程C，那么线程C是有可能获取到锁的，如果C获取到了锁，B就只能继续乖乖休眠了。

公平锁和非公平锁
概念很好理解，公平锁表示线程获取锁的顺序是按照线程加锁的顺序来分配，即先进先出，那么他就是公平的；非公平是一种抢占机制，是随机获得锁，并不是先来的一定能先得到锁，结果就是不公平的。

ReentrantLock提供了一个构造方法，可以很简单的实现公平锁或非公平锁，源代码构造函数如下：

public ReentrantLock(boolean fair) {
   sync = fair ? new FairSync() : new NonfairSync();
}

参数：fair为true表示是公平锁，反之为非公平锁。

synchronized和lock实现同步代码如下：
在这里插入图片描述

Lock与synchronized的区别
1)Lock是显示锁(手动开启和关闭锁，别忘关闭锁),synchronized是隐式锁
2)Lock只有代码块锁，synchronized 有代码块锁和方法锁
3)使用Lock锁，JVM将花费较少的时间来调度线程，性能更好，并且具有更好的扩展性(提供更多的子类)
4)Lock确保当一个线程位于代码的临界区时，另一个线程不进入临界区。如果其他线程试图进入锁定的代码，则它将一直等待(即被阻止)，直到该对象被释放。lock()方法会对Lock实例对象进行加锁,因此所有对该对象调用lock()方法的线程都会被阻塞，直到该Lock对象的unlock()方法被调用
5) Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。Lock可以提高多个线程进行读操作的效率。
6) ReentrantLock可重入锁是一种递归无阻塞的同步锁机制，简单意思就是说可重入锁就是当前持有该锁的线程能够多次获取该锁，无需等待。

代码示例(使用ReentrantLock实现线程同步)：
在这里插入图片描述

public class Run {

    public static void main(String[] args) {

        Lock lock = new ReentrantLock();
		//lambda写法
        new Thread(() -> runMethod(lock, 0), "thread1").start();
        new Thread(() -> runMethod(lock, 5000), "thread2").start();
        new Thread(() -> runMethod(lock, 1000), "thread3").start();
        new Thread(() -> runMethod(lock, 5000), "thread4").start();
        //常规写法
        new Thread(new Runnable() {
            @Override
            public void run() {
                runMethod(lock,1000);
            }
        }, "thread5").start();
    }

    private static void runMethod(Lock lock, long sleepTime) {
        lock.lock();
        try {
            Thread.sleep(sleepTime);
            System.out.println("ThreadName:" + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }
}

详细可看：
https://blog.csdn.net/fuzhongmin05/article/details/63682947
https://blog.csdn.net/yalu_123456/article/details/91050036
使用Lock对象实现线程间通信
在前文中我们已经知道可以使用关键字synchronized与wait()方法和notify()方式结合实现线程间通信，也就是等待/通知模式。在ReentrantLock中，是借助Condition对象进行实现的。

Condition的创建方式如下：

Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();

Condition按字面意思理解就是条件，当然，我们也可以将其认为是条件进行使用，这样的话我们可以通过上述的代码创建多个Condition条件，我们就可以根据不同的条件来控制现成的等待和通知。而我们还知道，在使用关键字synchronized与wait()方法和notify()方式结合实现线程间通信的时候，notify/notifyAll的通知等待的线程时是随机的，显然使用Condition相对灵活很多，可以实现”选择性通知”。

这是因为，synchronized关键字相当于整个Lock对象只有一个单一的Condition对象，所有的线程都注册到这个对象上。线程开始notifAll的时候，需要通知所有等待的线程，让他们开始竞争获得锁对象，没有选择权，这种方式相对于Condition条件的方式在效率上肯定Condition较高一些。
下边，我们首先看一个实例。
使用Lock对象和Condition实现等待/通知实例
主要方法对比如下：

（1）Object的wait()方法相当于Condition类中的await()方法；
（2）Object的notify()方法相当于Condition类中的signal()方法；
（3）Object的notifyAll()方法相当于Condition类中的signalAll()方法；

首先，使用Lock的时候需要先获取锁。

示例代码如下：

public class LockConditionDemo {

    private Lock lock = new ReentrantLock();
    private Condition condition = lock.newCondition();

    public static void main(String[] args) throws InterruptedException {

        //使用同一个LockConditionDemo对象，使得lock、condition一样
        LockConditionDemo demo = new LockConditionDemo();
        new Thread(() -> demo.await(), "thread1").start();
        Thread.sleep(3000);
        new Thread(() -> demo.signal(), "thread2").start();
    }

    private void await() {
        try {
            lock.lock();
            System.out.println("开始等待await！ ThreadName：" + Thread.currentThread().getName());
            condition.await();
            System.out.println("等待await结束！ ThreadName：" + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    private void signal() {
        lock.lock();
        System.out.println("发送通知signal！ ThreadName：" + Thread.currentThread().getName());
        condition.signal();
        lock.unlock();
    }
}

运行结果：

开始等待await！ ThreadName：thread1
发送通知signal！ ThreadName：thread2
等待await结束！ ThreadName：thread1

可以看出结果正确执行！

使用Lock对象和多个Condition实现等待/通知实例
示例代码如下：

public class LockConditionDemo {

    private Lock lock = new ReentrantLock();
    private Condition conditionA = lock.newCondition();
    private Condition conditionB = lock.newCondition();

    public static void main(String[] args) throws InterruptedException {

        LockConditionDemo demo = new LockConditionDemo();

        new Thread(() -> demo.await(demo.conditionA), "thread1_conditionA").start();
        new Thread(() -> demo.await(demo.conditionB), "thread2_conditionB").start();
        new Thread(() -> demo.signal(demo.conditionA), "thread3_conditionA").start();
        System.out.println("稍等5秒再通知其他的线程！");
        Thread.sleep(5000);
        new Thread(() -> demo.signal(demo.conditionB), "thread4_conditionB").start();

    }

    private void await(Condition condition) {
        try {
            lock.lock();
            System.out.println("开始等待await！ ThreadName：" + Thread.currentThread().getName());
            condition.await();
            System.out.println("等待await结束！ ThreadName：" + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    private void signal(Condition condition) {
        lock.lock();
        System.out.println("发送通知signal！ ThreadName：" + Thread.currentThread().getName());
        condition.signal();
        lock.unlock();
    }
}

运行结果：

开始等待await！ ThreadName：thread1_conditionA
开始等待await！ ThreadName：thread2_conditionB
发送通知signal！ ThreadName：thread3_conditionA
等待await结束！ ThreadName：thread1_conditionA
稍等5秒再通知其他的线程！
发送通知signal！ ThreadName：thread4_conditionB
等待await结束！ ThreadName：thread2_conditionB

可以看出实现了分别通知。因此，我们可以使用Condition进行分组，可以单独的通知某一个分组，另外还可以使用signalAll()方法实现通知某一个分组的所有等待的线程。

ReentrantLock的其他方法
方法很简单，看到名称就可以想到作用是什么，挑一些简单介绍一下：
（1）getHoldCount()方法：查询当前线程保持此锁定的个数，也就是调用lock()的次数；
（2）getQueueLength()方法：返回正等待获取此锁定的线程估计数目；
（3）isFair()方法：判断是不是公平锁；

使用ReentrantReadWriteLock实现并发
上述的类ReentrantLock具有完全互斥排他的效果，即同一时间只能有一个线程在执行ReentrantLock.lock()之后的任务。

类似于我们集合中有同步类容器和并发类容器，HashTable（HashTable几乎可以等价于HashMap，并且是线程安全的）也是完全排他的，即使是读也只能同步执行，而ConcurrentHashMap就可以实现同一时刻多个线程之间并发。为了提高效率，ReentrantLock的升级版ReentrantReadWriteLock就可以实现效率的提升。

ReentrantReadWriteLock有两个锁：一个是与读相关的锁，称为“共享锁”；另一个是与写相关的锁，称为“排它锁”。也就是多个读锁之间不互斥，读锁与写锁互斥，写锁与写锁互斥。

在没有线程进行写操作时，进行读操作的多个线程都可以获取到读锁，而写操作的线程只有获取写锁后才能进行写入操作。即：多个线程可以同时进行读操作，但是同一时刻只允许一个线程进行写操作。

ReentrantReadWriteLock锁的特性：

（1）读读共享；
（2）写写互斥；
（3）读写互斥；
（4）写读互斥；

ReentrantReadWriteLock实例代码
（1）读读共享

public class ReentrantReadWriteLockDemo {

    private ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

    public static void main(String[] args) {

        ReentrantReadWriteLockDemo demo = new ReentrantReadWriteLockDemo();

        new Thread(() -> demo.read(), "ThreadA").start();
        new Thread(() -> demo.read(), "ThreadB").start();
    }

    private void read() {
        try {
            try {
                lock.readLock().lock();
                System.out.println("获得读锁" + Thread.currentThread().getName()
                        + " 时间:" + System.currentTimeMillis());
                //模拟读操作时间为5秒
                Thread.sleep(5000);
            } finally {
                lock.readLock().unlock();
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

执行结果：

获得读锁ThreadA 时间:1507720692022
获得读锁ThreadB 时间:1507720692022

可以看出两个线程之间，获取锁的时间几乎同时，说明lock.readLock().lock(); 允许多个线程同时执行lock（）方法后面的代码。
（2）写写互斥

public class ReentrantReadWriteLockDemo {

    private ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

    public static void main(String[] args) {

        ReentrantReadWriteLockDemo demo = new ReentrantReadWriteLockDemo();

        new Thread(() -> demo.write(), "ThreadA").start();
        new Thread(() -> demo.write(), "ThreadB").start();
    }

    private void write() {
        try {
            try {
                lock.writeLock().lock();
                System.out.println("获得写锁" + Thread.currentThread().getName()
                        + " 时间:" + System.currentTimeMillis());
                //模拟写操作时间为5秒
                Thread.sleep(5000);
            } finally {
                lock.writeLock().unlock();
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

执行结果：

获得写锁ThreadA 时间:1507720931662
获得写锁ThreadB 时间:1507720936662

可以看出执行结果大致差了5秒的时间，可以说明多个写线程是互斥的。
（3）读写互斥或写读互斥

public class ReentrantReadWriteLockDemo {

    private ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

    public static void main(String[] args) throws InterruptedException {
        ReentrantReadWriteLockDemo demo = new ReentrantReadWriteLockDemo();

        new Thread(() -> demo.read(), "ThreadA").start();
        Thread.sleep(1000);
        new Thread(() -> demo.write(), "ThreadB").start();
    }

    private void read() {
        try {
            try {
                lock.readLock().lock();
                System.out.println("获得读锁" + Thread.currentThread().getName()
                        + " 时间:" + System.currentTimeMillis());
                Thread.sleep(3000);
            } finally {
                lock.readLock().unlock();
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    private void write() {
        try {
            try {
                lock.writeLock().lock();
                System.out.println("获得写锁" + Thread.currentThread().getName()
                        + " 时间:" + System.currentTimeMillis());
                Thread.sleep(3000);
            } finally {
                lock.writeLock().unlock();
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

执行结果：

获得读锁ThreadA 时间:1507721135908
获得写锁ThreadB 时间:1507721138908

可以看出执行结果大致差了3秒的时间，可以说明读写线程是互斥的。

扩展：
1）ConcurrentHashMap的并发度是什么
ConcurrentHashMap的并发度就是segment的大小，默认为16，这意味着最多同时可以有16条线程操作ConcurrentHashMap
2）Linux环境下如何查找哪个线程使用CPU最长
1）获取java进程的pid，jps或者ps -ef | grep java
2）top -H -p pid，顺序不能改变
（-p: 显示指定PID的进程 -H：设置线程模式）

死锁：

多个线程各自占有一些共享资源 , 并且互相等待其他线程占有的资源才能运行 , 而导致两个或者多个线程都在等待对方释放资源 ,
都停止执行的情形 .
某一个同步块同时拥有 “ 两个以上对象的锁 ” 时 , 就可能会发生 “ 死锁 ” 的问题 .

Java发生死锁的根本原因是：在申请锁时发生了交叉闭环申请。

死锁避免方法：

产生死锁的四个必要条件：

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

上面列出了死锁的四个必要条件，我们只要想办法破其中的任意一个或多个条件
就可以避免死锁发生
总之是尽量避免在一个同步方法中调用其它对象的延时方法和同步方法。

案例：
//死锁问题
//两个线程抱着自己的锁 , 然后想要对方的锁 .
// 于是产生一个问题 —> 死锁


public class DeadLocked {

    public static void main(String[] args) {
        Makeup g1 = new Makeup(0,"白雪公主");
        Makeup g2 = new Makeup(1,"灰姑凉");

        new Thread(g1).start();
        new Thread(g2).start();

    }
}

//化妆
class Makeup implements Runnable{

    //选择
    int choice;
    //谁进来了
    String girlName;

    //两个对象
    static LipStick lipStick = new LipStick();
    static Mirror mirror = new Mirror();

    public Makeup(int choice,String girlName){
        this.choice = choice;
        this.girlName = girlName;
    }

    @Override
    public void run() {
        //化妆
        try {
            makeup();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    //化妆的方法
    public void makeup() throws InterruptedException {
        if (choice==0){ //先拿口红,再拿镜子
            synchronized (lipStick){
                System.out.println("拿到口红");
                Thread.sleep(1000);
                //等待拿镜子的人释放锁
                synchronized (mirror){
                    System.out.println("拿到镜子");
                }
            }

        }else { //先拿镜子 , 再拿口红
            synchronized (mirror){
                System.out.println("拿到镜子");
                Thread.sleep(2000);
                //等待拿口红的人释放锁
                synchronized (lipStick){
                    System.out.println("拿到口红");
                }
            }
        }

    }

}
//口红
class LipStick{

}
//镜子
class Mirror{

}

结果输出：
程序死了

1.5) 谈谈 synchronized和ReenTrantLock 的区别
① 两者都是可重入锁
两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API
synchronized 是依赖于 JVM 实现的，前面我们也讲到了虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReenTrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock 方法配合 try/ﬁnally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
synchronized是和if、else、for、while一样的关键字，ReentrantLock是类，这是二者的本质区别。既然ReentrantLock是类，那么它就提供了比synchronized更多更灵活的特性，可以被继承、可以有方法、可以有各种各样的类变量，ReentrantLock比synchronized的扩展性体现在几点上：

1）ReentrantLock可以对获取锁的等待时间进行设置，这样就避免了死锁

2）ReentrantLock可以获取各种锁的信息

3）ReentrantLock可以灵活地实现多路通知

③ 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是一个不错的选择。
④ 性能已不是选择标准
在JDK1.6之前，synchronized 的性能是比 ReenTrantLock 差很多。具体表示为：synchronized 关键字吞吐量岁线程数的增加，下降得非常严重。而ReenTrantLock 基本保持一个比较稳定的水平。我觉得这也侧面反映了， synchronized 关键字还有非常大的优化余地。后续的技术发展也证明了这一点，我们上面也讲了在 JDK1.6 之后 JVM 团队对 synchronized 关键字做了很多优化。JDK1.6 之后，synchronized 和 ReenTrantLock 的性能基本是持平了。所以网上那些说因为性能才选择 ReenTrantLock 的文章都是错的！JDK1.6之后，性能已经不是选择synchronized和ReenTrantLock的影响因素了！而且虚拟机在未来的性能改进中会更偏向于原生的synchronized，所以还是提倡在synchronized能满足你的需求的情况下，优先考虑使用synchronized关键字来进行同步！优化后的synchronized和ReenTrantLock一样，在很多地方都是用到了CAS操作。

面试：Concurrency API中的Lock接口(Lockinterface)是什么？对比同步它有什么优势？
Lock接口比同步方法和同步块提供了更具扩展性的锁操作。他们允许更灵活的结构，可以具有完全不同的性质，并且可以支持多个相关类的条件对象。
它的优势有：
可以使锁更公平
可以使线程在等待锁的时候响应中断
可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间
可以在不同的范围，以不同的顺序获取和释放锁

其他实现线程同步的方法：
使用局部变量实现线程同步:
ThreadLocal是什么？有什么用？
ThreadLocal是一个本地线程副本变量工具类。主要用于将私有线程和该线程存放的副本对象做一个映射，各个线程之间的变量互不干扰，在高并发场景下，可以实现无状态的调用，特别适用于各个线程依赖不同的变量值完成操作的场景。
简单说ThreadLocal就是一种以空间换时间的做法，在每个Thread里面维护了一个以开地址法实现的ThreadLocal.ThreadLocalMap，把数据进行隔离，数据不共享，自然就没有线程安全方面的问题了。

如果使用ThreadLocal管理变量，则每一个使用该变量的线程都获得该变量的副本，副本之间相互独立，这样每一个线程都可以随意修改自己的变量副本，而不会对其他线程产生影响。
ThreadLocal是Java里一种特殊的变量。每个线程都有一个ThreadLocal就是每个线程都拥有了自己独立的一个变量，竞争条件被彻底消除了。它是为创建代价高昂的对象获取线程安全的好方法，比如你可以用ThreadLocal让SimpleDateFormat变成线程安全的，因为那个类创建代价高昂且每次调用都需要创建不同的实例所以不值得在局部范围使用它，如果为每个线程提供一个自己独有的变量拷贝，将大大提高效率。首先，通过复用减少了代价高昂的对象的创建个数。其次，你在没有使用高代价的同步或者不变性的情况下获得了线程安全。线程局部变量的另一个不错的例子是ThreadLocalRandom类，它在多线程环境中减少了创建代价高昂的Random对象的个数。
ThreadLocal 类的常用方法：

ThreadLocal() : 创建一个线程本地变量

get() : 返回此线程局部变量的当前线程副本中的值

initialValue() : 返回此线程局部变量的当前线程的"初始值"

set(T value) : 将此线程局部变量的当前线程副本中的值设置为value
在这里插入图片描述
使用原子变量实现线程同步
需要使用线程同步的根本原因在于对普通变量的操作不是原子的。

那么什么是原子操作呢？原子操作就是指将读取变量值、修改变量值、保存变量值看成一个整体来操作。这几种行为要么同时完成，要么都不完成。在java的util.concurrent.atomic包中提供了创建原子类型变量的工具类，使用该类可以简化线程同步。其中AtomicInteger 表可以用原子方式更新int的值，可用在应用程序中(如以原子方式增加的计数器)，但不能用于替换Integer。 AtomicInteger类常用方法：AtomicInteger(int initialValue) : 创建具有给定初始值的变量。AtomicIntegeraddAddGet(int dalta) : 以原子方式将给定值与当前值相加。
get() : 获取当前值。
在这里插入图片描述
面试一、处理器如何实现原子操作
处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。
1、使用总线加锁
所谓总线锁就是使用处理器提供的一个Lock#信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住，那么该处理器可以独占共享内存。
2、使用缓存锁定
在同一时刻，我们只需保证对某个内存地址的操作时原子性即可，但总线锁定把CPU和内存之间的通信锁住了，开销比较大，目前处理器在某些场合下使用缓存锁定来进行优化
缓存锁定是指内存区域如果被缓存在处理器的缓存行中，并且在Lock操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不再总线上声言Lock#信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性会阻止同时修改两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时，会使缓存行无效。
但是有两种情况处理器不会使用缓存锁定：
1）当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行时，处理器会使用总线锁定
2）有些处理器不执行缓存锁定。

面试二、Java是如何实现原子操作的
1）循环CAS实现原子操作
2）使用锁机制实现原子操作
锁机制保证了只有获得锁的线程才能够操作锁定的内存区域。

3.AQS
1）什么是AQS
AQS是AbustactQueuedSynchronizer的简称，它是一个Java提高的底层同步工具类，用一个int类型的变量表示同步状态，并提供了一系列的CAS操作来管理这个同步状态。
AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。

2)AQS支持两种同步方式：
1）独占式
2）共享式
这样方便使用者实现不同类型的同步组件，独占式如ReentrantLock，共享式如Semaphore，CountDownLatch，组合式的如ReentrantReadWriteLock。总之，AQS为使用提供了底层支撑，如何组装实现，使用者可以自由发挥。

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

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

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

看个AQS(AbstractQueuedSynchronizer)原理图：
在这里插入图片描述
AQS，它维护了一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。这里volatile是核心关键词，具体volatile的语义，在此不述。state的访问方式有三种:

getState()
setState()
compareAndSetState()
AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。

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

isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)：共享方式。尝试释放资源，成功则返回true，失败则返回false。
以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。

二、面试中关于线程池的 4 连
2.1）讲一下Java内存模型
在这里插入图片描述
Java 虚拟机规范中试图定义一种 Java 内存模型（Java Memory Model, JMM）来屏蔽掉各层硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。
Java 内存模型规定了所有的变量都存储在主内存（Main Memory）中。每条线程还有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，**线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。**不同的线程之间也无法直接访问对方工作内存中的变量，线程间的变量值的传递均需要通过主内存来完成，线程、主内存、工作内存三者的关系如上图。

在 JDK1.2 之前，Java的内存模型实现总是从主存（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量(其实是变量副本)保存本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。
在这里插入图片描述
要解决这个问题，就需要把变量声明为 volatile，这就指示 JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。
说白了， volatile 关键字的主要作用就是保证变量的可见性然后还有一个作用是防止指令重排序。
在这里插入图片描述
volatile关键字的作用
对于可见性，Java提供了volatile关键字来保证可见性。
当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。
从实践角度而言，volatile的一个重要作用就是和CAS结合，保证了原子性，详细的可以参见java.util.concurrent.atomic包下的类，比如AtomicInteger。

线程B怎么知道线程A修改了变量
volatile修饰变量
synchronized修饰修改变量的方法
wait/notify
while轮询

2.2）说说 synchronized 关键字和 volatile 关键字的区别
synchronized关键字和volatile关键字比较

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