1 基本概括

2 文章详情

1.1 Java基础——Java多线程（进程与线程的介绍）

1.2 Java基础——Java多线程（线程的创建方式）

1.3 Java基础——Java多线程（什么是进程？）

1.4 Java基础——Java多线程(什么是线程?)

1.5 Java基础——Java多线程(什么是线程池?)

1.6 Java基础——Java多线程（什么是线程安全？）

1.7 Java基础——Java多线程（多线程死锁问题）

1.8 Java基础——Java多线程（ThreadLocal详解）

1.9 Java基础——Java多线程（进程与线程间通信方式）

1.10 Java基础——Java多线程（volalite详解）

1.11 Java基础——Java多线程（synchronized详解）

1.12 Java基础——Java多线程（synchronized优化）

1.13 Java基础——Java多线程（锁的介绍）

1.14 Java基础——Java多线程（Lock接口详解）

3 问题总结

3.1 进程与线程的介绍相关问题

3.1.1 进程与线程之间的联系

1、一个线程只能属于一个进程，而一个进程可以有多个线程，但至少有一个线程（通常说的主线程）。

2、资源分配给进程，同一进程的所有线程共享该进程的所有资源。

3、线程在执行过程中，需要协作同步。不同进程的线程间要利用消息通信的办法实现同步。

4、处理机分给线程，即真正在处理机上运行的是线程。5、线程是指进程内的一个执行单元，也是进程内的可调度实体。

3.1.2 进程与程序之间的区别

1、进程是动态的，程序是静态的。程序是有序代码的集合，进程是程序执行的过程。

2、进程是暂时的，程序是永久的。进程是一个状态变化的过程，程序可永久保存。

3、进程与程序的对应关系。通过多次执行，一个程序可对应多个进程；通过调用关系，一个进程可包括多个程序。

4、进程和程序的组成不同。进程的组成包括程序，数据和PCB。

3.2 什么是进程相关问题

3.2.1 JAVA进程突然消失问题以及解决方案

无外乎三种情况。

1 linux的OOM killer杀死

解决方案：

Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。

因此，你发现java进程突然没了，首先要怀疑是不是被linux的OOM killer给干掉了！

你可以去下面这个文件里翻系统报错日志:/var/log/messages

你执行命令

egrep -i 'killed process' /var/log/messages

去日志里进行查询。

当然，你也可以去内核日志里头查询。有时Linux系统或者系统上运行的java或者其它进程，会发生一些莫名其妙的问题，比如突然挂掉了，比如突然重启等等。在软件上找不到问题所在，此时我们应该怀疑硬件或者内核的问题，此时我们就可以使用 dmesg来查看：

dmesg | grep java

输出如下

 [5673702.665338] Out of memory: Kill process 29953 (java) score 431 or sacrifice child[5673702.665338] Killed process 29953, UID 500, (java) total-vm:9805316kB, anon-rss:2344496kB, file-rss:128kB

完全是可以看到内核对进程做对操作。

2 JVM自身故障

解决方案：

当JVM发生致命错误导致崩溃时，会生成一个hs_err_pid_xxx.log这样的文件，该文件包含了导致 JVM crash 的重要信息，我们可以通过分析该文件定位到导致 JVM Crash 的原因，从而修复保证系统稳定。默认情况下，该文件是生成在工作目录下的，当然也可以通过 JVM 参数指定生成路径：

-XX:ErrorFile=/var/log/hs_err_pid.log

这个文件的内容他主要有如下内容

  • 日志头文件
  • 导致 crash 的线程信息
  • 所有线程信息
  • 安全点和锁信息
  • 堆信息
  • 本地代码缓存
  • 编译事件
  • gc 相关记录
  • jvm 内存映射
  • jvm 启动参数
  • 服务器信息

拿到这个文件后，需要仔细的分析。

3 jvm的OOM导致进程退出比较罕见

解决方案：

很少遇到JVM的OOM，导致java进程退出的情况。

因为，一般情况下，出现OOM异常，JVM的GC会进行回收，是不会导致JVM进程退出的。要真说唯一导致 退出的情况，那就是内存泄漏，由于内存占用越来越大，结果。。。。

不过这种JVM的OOM导致的异常，很好排查。

因为，你注意两个个参数

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=*/java.hprof；

然后去找dump快照文件，接下来借助VisualVM这种可视化工具分析就行。很容易定位问题。

总结：

综上所述，正确回答是。先翻dump文件，dump如果没有，翻hs_err_pid.log日志。如果还没有，翻内核日志。

3.2.2 Java进程cpu占用过高问题以及解决方案

出现原因大概有以下几种情况：

1、Java 内存不够或溢出导致GC overhead问题, GC overhead 导致的CPU 100%问题;

2、死循环问题. 如常见的HashMap被多个线程并发使用导致的死循环, 或者死循环;

3、某些操作一直占用CPU

解决方案

第一步：使用top命令，查看占用cpu的进程

第二步：ps -ef | grep java 或jps命令，找出服务器的所有java进程

第三步：找出CPU耗用最厉害的进程pid

第四步：查找出具体占用cpu利用率最厉害的线程号，top -H -p pid 。然后按下shift+p，跳出CPU监控当前线程号为：1747

第五步：将获取到的线程号转换成16进制

第六步：导出线程栈

将具体的占用CPU过高的java进程的线程栈导出，导出命令如下：

pid.tdump文件后缀名随意，通常以tdump结尾。

第七步：导出堆

第八步：jvisualvm分析快照使用JAVA_HOME/bin/jvisualvm.exe，载入快照

3.2.3 java 进程是如何在Linux服务器上进行内存分配的

Java进程在启动的时候我们可以通过 -Xms 和-Xmx来设置内存的上限和下限。直到我发现使用top命令监控的Java进程在-Xms设置4g的情况下占用的内存并不是4g，这就产生了一个疑问Linux服务器的内存到底是如何进行分配的。

在Linux上运行的进程不仅限于Java。都有一个概念，逻辑内存(Logic Memory)，而物理机真是持有的内存，我们称为 物理内存(Physic Memory)。

进程在开始运行时并不会直接分配物理内存，进程只是傻乎乎的以为自己持有了内存，也就是逻辑内存。当程序运行需要内存分配的时候，Linux服务器会以页的(Page)至小4k的方式分配，并一对一映射物理内存和逻辑内存的关系，看到了吗这里其实用了代理的思想是得内存的分配进行了解耦。

这样做的好处是什么呢? 1进程之间相互隔离 2进程自己认为占有了一段独立连续的内存 3可以申请比物理内存更大的内存空间。

第三点怎么理解呢?其实Linux在这里设计了一种机制叫Swap 就是在进程分配的内存空间超过物理内存的时候，如果各个进程运行所占的内存真的有这么多，超过了物理内存就会触发Swap，把不持有CPU的部分进程的内存数据和磁盘进行io数据交换。因为CPU一时间不可能超过所有占有的内存，所以这种优化就造就了能多申请一些内存，大概是原来内存的2-3倍，这就很可观了，毕竟内存是非常贵的。

Swap虽然好，也带来了一些问题。

比如频繁的Swap，这会导致内存操作转化为磁盘的的IO操作，拖慢应用进程的运行速度。所以说Swap在我的理解里属于可以应急不使进程崩溃，适当使用可以减少成本，过分了不当人的使用就会被反噬的机制。

当然如果太不当人，进程还是会崩溃了，Swap是一个类似Buffer的机制，有大小的。超过设置的上限，Kernel内核就会触发OOM Killer，杀死一部分进程腾空间。

3.2.4 OutOfMemoryError，内存不足

第一种OutOfMemoryError： PermGenspace

发生这种问题的原因是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与PermanentGeneration space有关。解决这类问题有以下两种办法：1.增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。如针对tomcat6.0，在catalina.sh或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右） 增加一行：JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m"如果是windows服务器还可以在系统环境变量中设置。感觉用tomcat发布sprint+struts+hibernate架构的程序时很容易发生这种内存溢出错误。使用上述方法，我成功解决了部署ssh项目的tomcat服务器经常宕机的问题。2.清理应用程序中web-inf/lib下的jar，如果tomcat部署了多个应用，很多应用都使用了相同的jar，可以将共同的jar移到tomcat共同的lib下，减少类的重复加载。这种方法是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是第一种方法。

第二种OutOfMemoryError： Java heap space

发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heapspace有关。解决这类问题有两种思路：1. 检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了Javaheap space的内存溢出问题，后来通过修改程序得到了解决。2. 增加Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m-Xmx1024m

第三种OutOfMemoryError：unable to create new nativethread

这种错误在Java线程个数很多的情况下容易发生

3.3 什么是线程相关问题

3.3.1 什么是Java线程转储(Thread Dump)，如何得到它？

线程转储是一个JVM活动线程的列表，它对于分析系统瓶颈和死锁非常有用。有很多方法可以获取线程转储——使用Profiler，Kill-3命令，jstack工具等等。有的更喜欢jstack工具，因为它容易使用并且是JDK自带的。由于它是一个基于终端的工具，所以可以编写一些脚本去定时的产生线程转储以待分析。

3.3.2 什么是死锁(Deadlock)？如何分析和避免死锁？

死锁是指两个以上的线程永远阻塞的情况，这种情况产生至少需要两个以上的线程和两个以上的资源。

分析死锁，我们需要查看Java应用程序的线程转储。我们需要找出那些状态为BLOCKED的线程和他们等待的资源。每个资源都有一个唯一的id，用这个id我们可以找出哪些线程已经拥有了它的对象锁。

避免嵌套锁，只在需要的地方使用锁和避免无限期等待是避免死锁的通常办法。

3.3.3 sleep方法和wait方法的相同点和不同点？

1 相同点：

　　　　　　一旦执行方法，都可以使得当前的线程进入阻塞状态

2 不同点：

　　　　　1 两个方法的声明的位置不同，Thread 类只声明的sleep().Object 类中声明wait();

　　　　　2 调用的要求不同，sleep()可以在任何需要的场景下调用，wait()必须在同步代码块中或者同步方法中的监视器中

　　　　　3 关于是否释放同步监视器，如果两方法都是使用在同步代码块或同步方法中，sleep（）不会释放锁，wait()会释放锁。

3.3.4 用户线程与内核线程的区别

用户线程和内核线程的区别

1 .内核级线程:切换由内核控制，当线程进行切换的时候，由用户态转化为内核态。切换完毕要从内核态返回用户态；可以很好的利用smp，即利用多核cpu。windows线程就是这样的。

2. 用户级线程内核的切换由用户态程序自己控制内核切换,不需要内核干涉，少了进出内核态的消耗，但不能很好的利用多核Cpu,目前Linux pthread大体是这么做的。

线程的实现可以分为两类：用户级线程(User-Level Thread)和内核线线程(Kernel-Level Thread)，后者又称为内核支持的线程或轻量级进程。在多线程操作系统中，各个系统的实现方式并不相同，在有的系统中实现了用户级线程，有的系统中实 现了内核级线程。

用户线程指不需要内核支持而在用户程序中实现的线程，其不依赖于操作系统核心，应 用进程利用线程库提供创建、同步、调度和管理线程的函数来控制用户线程。不需要用户态/核心态切换，速度快，操作系统内核不知道多线程的存在，因此一个线 程阻塞将使得整个进程（包括它的所有线程）阻塞。由于这里的处理器时间片分配是以进程为基本单位，所以每个线程执行的时间相对减少。

内核线程：由操作系统内核创建和撤销。内核维护进程及线程的上下文信息以及线程切换。一个内核线程由于I/O操作而阻塞，不会影响其它线程的运行。Windows NT和2000/XP支持内核线程。

用户线程运行在一个中间系统上面。目 前中间系统实现的方式有两种，即运行时系统（Runtime System）和内核控制线程。“运行时系统”实质上是用于管理和控制线程的函数集合，包括创建、撤销、线程的同步和通信的函数以及调度的函数。这些函数 都驻留在用户空间作为用户线程和内核之间的接口。用户线程不能使用系统调用，而是当线程需要系统资源时，将请求传送给运行时，由后者通过相应的系统调用来 获取系统资源。内核控制线程：系统在分给进程几个轻型进程（LWP），LWP可以通过系统调用来获得内核提供的服务，而进程中的用户线程可通过复用来关联 到LWP，从而得到内核的服务。

以下是用户级线程和内核级线程的区别：

（1）内核支持线程是OS内核可感知的，而用户级线程是OS内核不可感知的。

（2）用户级线程的创建、撤消和调度不需要OS内核的支持，是在语言（如Java）这一级处理的；而内核支持线程的创建、撤消和调度都需OS内核提供支持，而且与进程的创建、撤消和调度大体是相同的。

（3）用户级线程执行系统调用指令时将导致其所属进程被中断，而内核支持线程执行系统调用指令时，只导致该线程被中断。

（4）在只有用户级线程的系统内，CPU调度还是以进程为单位，处于运行状态的进程中的多个线程，由用户程序控制线程的轮换运行；在有内核支持线程的系统内，CPU调度则以线程为单位，由OS的线程调度程序负责线程的调度。

（5）用户级线程的程序实体是运行在用户态下的程序，而内核支持线程的程序实体则是可以运行在任何状态下的程序。

内核线程的优点：

（1）当有多个处理机时，一个进程的多个线程可以同时执行。

缺点：

（1）由内核进行调度。

用户进程的优点：

（1） 线程的调度不需要内核直接参与，控制简单。

（2） 可以在不支持线程的操作系统中实现。

（3） 创建和销毁线程、线程切换代价等线程管理的代价比内核线程少得多。

（4） 允许每个进程定制自己的调度算法，线程管理比较灵活。

（5） 线程能够利用的表空间和堆栈空间比内核级线程多。

（6） 同一进程中只能同时有一个线程在运行，如果有一个线程使用了系统调用而阻塞，那么整个进程都会被挂起。另外，页面失效也会产生同样的问题。

缺点：

（1）资源调度按照进程进行，多个处理机下，同一个进程中的线程只能在同一个处理机下分时复用

3.3.5 线程的状态

1. 新建(NEW)：新创建了一个线程对象。

2. 可运行(RUNNABLE)：线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权 。

3. 运行(RUNNING)：可运行状态(runnable)的线程获得了cpu 时间片（timeslice） ，执行程序代码。4. 阻塞(BLOCKED)：阻塞状态是指线程因为某种原因放弃了cpu 使用权，也即让出了cpu timeslice，暂时停止运行。直到线程进入可运行(runnable)状态，才有机会再次获得cpu timeslice 转到运行(running)状态。阻塞的情况分三种：

(一). 等待阻塞：运行(running)的线程执行o.wait()方法，JVM会把该线程放入等待队列(waitting queue)中。

(二). 同步阻塞：运行(running)的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入锁池(lock pool)中。

(三). 其他阻塞：运行(running)的线程执行Thread.sleep(long ms)或t.join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入可运行(runnable)状态。

5. 死亡(DEAD)：线程run()、main() 方法执行结束，或者因异常退出了run()方法，则该线程结束生命周期。死亡的线程不可再次复生。

3.3.6 方法比较

几个方法的比较

  1. Thread.sleep(long millis)，一定是当前线程调用此方法，当前线程进入阻塞，但不释放对象锁，millis后线程自动苏醒进入可运行状态。作用：给其它线程执行机会的最佳方式。
  2. Thread.yield()，一定是当前线程调用此方法，当前线程放弃获取的cpu时间片，由运行状态变会可运行状态，让OS再次选择线程。作用：让相同优先级的线程轮流执行，但并不保证一定会轮流执行。实际中无法保证yield()达到让步目的，因为让步的线程还有可能被线程调度程序再次选中。Thread.yield()不会导致阻塞。
  3. t.join()/t.join(long millis)，当前线程里调用其它线程1的join方法，当前线程阻塞，但不释放对象锁，直到线程1执行完毕或者millis时间到，当前线程进入可运行状态。
  4. obj.wait()，当前线程调用对象的wait()方法，当前线程释放对象锁，进入等待队列。依靠notify()/notifyAll()唤醒或者wait(long timeout)timeout时间到自动唤醒。
  5. obj.notify()唤醒在此对象监视器上等待的单个线程，选择是任意性的。notifyAll()唤醒在此对象监视器上等待的所有线程。

3.3.7 线程同步，有三个比较重要的性质

原子性：一个操作或多个操作要么全部执行完成且执行过程不被中断，要么就不执行。

可见性：当多个线程同时访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

有序性：程序执行的顺序按照代码的先后顺序执行。

3.4 什么是线程池相关问题

3.4.1 使用线程池比手动创建线程好在哪里？

1 可以将任务的提交和执行策略解耦，便于统一管理任务执行策略，好维护，比如延时执行，设置等 待时间，超时自动失败等。

2 提高性能，用已创建的线程执行任务，减少创建和销毁线程的开销。

3 约束最大线程并发数，防止无止境创建线程造成性能变差以及程序死掉。

4 活跃线程数、最大线程数等参数可配置，方便进行性能调优。

3.4.2 线程池的各参数的含义？

第1个参数 ：corePoolSize 表示常驻核心线程数。如果等于0，则任务执行完成后，没有任何请求进入时销毁线程池的线程；如果大于0，即使本地任务执行完毕，核心线程也不会被销毁。这个值的设置非常关键，设置过大会浪费资源，设置的过小会导致线程频繁地创建或销毁。

第2个参数：maximumPoolSize 表示线程池能够容纳同时执行的最大线程数。从上方的示例代码中第一处来看，必须大于或等于1。如果待执行的线程数大于此值，需要借助第5个参数的帮助。缓存在队列中。如果maximumPoolSize 与corePoolSize 相等，即是固定大小线程池。

第3个参数：keepAliveTime 表示线程池中的线程空闲时间，当空闲时间达到KeepAliveTime 值时，线程被销毁，直到剩下corePoolSize 个线程为止，避免浪费内存和句柄资源。在默认情况下，当线程池的线程大于corePoolSize 时，keepAliveTime 才会起作用。但是ThreadPoolExecutor的allowCoreThreadTimeOut 变量设置为ture时，核心线程超时后也会被回收。

第4个参数：TimeUnit 表示时间单位。keepAliveTime 的时间单位通常是TimeUnit.SECONDS。

第5个参数: workQueue 表示缓存队列。当请求的线程数大于maximumPoolSize时，线程进入BlockingQueue 阻塞队列。后续示例代码中使用的LinkedBlockingQueue 是单向链表，使用锁来控制入队和出对的原子性，两个锁分别控制元素的添加和获取，是一个生产消费模型队列。

第6个参数：threadFactory 表示线程工厂。它用来生产一组相同任务的线程。线程池的命名是通过给这个factory增加组名前缀来实现的。在虚拟机栈分析时，就可以知道线程任务是由哪个线程工厂产生的。

第7个参数：handler 表示执行拒绝策略的对象。当超过第5个参数workQueue的任务缓存区上限的时候，就可以通过该策略处理请求，这是一种简单的限流保护。友好的拒绝策略可以使如下三种：

  1. 保存到数据库进行削峰填谷。在空闲的时候再拿出来执行。
  2. 转向某个提示页面。
  3. 打印日志。

3.4.3 线程池有哪 4 种拒绝策略？

1 CallerRunsPolicy（调用者运行策略）

public static class CallerRunsPolicy implements RejectedExecutionHandler {public CallerRunsPolicy() { }public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {if (!e.isShutdown()) {r.run();}}
}

功能：当触发拒绝策略时，只要线程池没有关闭，就由提交任务的当前线程处理。

使用场景：一般在不允许失败的、对性能要求不高、并发量较小的场景下使用，因为线程池一般情况下不会关闭，也就是提交的任务一定会被运行，但是由于是调用者线程自己执行的，当多次提交任务时，就会阻塞后续任务执行，性能和效率自然就慢了。

2 AbortPolicy（中止策略）

public static class AbortPolicy implements RejectedExecutionHandler {public AbortPolicy() { }public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {throw new RejectedExecutionException("Task " + r.toString() +" rejected from " +e.toString());}
}

功能：当触发拒绝策略时，直接抛出拒绝执行的异常，中止策略的意思也就是打断当前执行流程

使用场景：这个就没有特殊的场景了，但是一点要正确处理抛出的异常。ThreadPoolExecutor中默认的策略就是AbortPolicy，ExecutorService接口的系列ThreadPoolExecutor因为都没有显示的设置拒绝策略，所以默认的都是这个。但是请注意，ExecutorService中的线程池实例队列都是无界的，也就是说把内存撑爆了都不会触发拒绝策略。当自己自定义线程池实例时，使用这个策略一定要处理好触发策略时抛的异常，因为他会打断当前的执行流程。

3 DiscardPolicy（丢弃策略）

public static class DiscardPolicy implements RejectedExecutionHandler {public DiscardPolicy() { }public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {}
}

功能：直接静悄悄的丢弃这个任务，不触发任何动作

使用场景：如果你提交的任务无关紧要，你就可以使用它 。因为它就是个空实现，会悄无声息的吞噬你的的任务。所以这个策略基本上不用了

4 DiscardOldestPolicy（弃老策略）

public static class DiscardOldestPolicy implements RejectedExecutionHandler {public DiscardOldestPolicy() { }public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {if (!e.isShutdown()) {e.getQueue().poll();e.execute(r);}}
}

功能：如果线程池未关闭，就弹出队列头部的元素，然后尝试执行

使用场景：这个策略还是会丢弃任务，丢弃时也是毫无声息，但是特点是丢弃的是老的未执行的任务，而且是待执行优先级较高的任务。基于这个特性，我能想到的场景就是，发布消息，和修改消息，当消息发布出去后，还未执行，此时更新的消息又来了，这个时候未执行的消息的版本比现在提交的消息版本要低就可以被丢弃了。因为队列中还有可能存在消息版本更低的消息会排队执行，所以在真正处理消息的时候一定要做好消息的版本比较

线程池触发拒绝策略的时机

和数据源连接池不一样，线程池除了初始大小和池子最大值，还多了一个阻塞队列来缓冲。数据源连接池一般请求的连接数超过连接池的最大值的时候就会触发拒绝策略，策略一般是阻塞等待设置的时间或者直接抛异常。而线程池的触发时机如下图

如图，想要了解线程池什么时候触发拒绝粗略，需要明确上面三个参数的具体含义，是这三个参数总体协调的结果，而不是简单的超过最大线程数就会触发线程拒绝粗略，当提交的任务数大于corePoolSize时，会优先放到队列缓冲区，只有填满了缓冲区后，才会判断当前运行的任务是否大于maxPoolSize，小于时会新建线程处理。大于时就触发了拒绝策略，总结就是：当前提交任务数大于（maxPoolSize + queueCapacity）时就会触发线程池的拒绝策略了。

3.4.4 有哪 6 种常见的线程池？什么是 Java8 的 ForkJoinPool？

1) FixedThreadPool

FixedThreadPool，它的核心线程数和最大线程数是一样的，所以可以把它看作是固定线程数的线程池，它的特点是线程池中的线程数除了初始阶段需要从 0 开始增加外，之后的线程数量就是固定的，就算任务数超过线程数，线程池也不会再创建更多的线程来处理任务，而是会把超出线程处理能力的任务放到任务队列中进行等待。而且就算任务队列满了，到了本该继续增加线程数的时候，由于它的最大线程数和核心线程数是一样的，所以也无法再增加新的线程了

2) CachedThreadPool

CachedThreadPool，可以称作可缓存线程池，它的特点在于线程数是几乎可以无限增加的（实际最大可以达到 Integer.MAX_VALUE，为 2^31-1，这个数非常大，所以基本不可能达到），而当线程闲置时还可以对线程进行回收。也就是说该线程池的线程数量不是固定不变的，当然它也有一个用于存储提交任务的队列，但这个队列是 SynchronousQueue，队列的容量为0，实际不存储任何任务，它只负责对任务进行中转和传递，所以效率比较高

3) ScheduledThreadPool

它支持定时或周期性执行任务。

4) SingleThreadExecutor

SingleThreadExecutor，它会使用唯一的线程去执行任务，原理和 FixedThreadPool 是一样的，只不过这里线程只有一个，如果线程在执行任务的过程中发生异常，线程池也会重新创建一个线程来执行后续的任务。这种线程池由于只有一个线程，所以非常适合用于所有任务都需要按被提交的顺序依次执行的场景，而前几种线程池不一定能够保障任务的执行顺序等于被提交的顺序，因为它们是多线程并行执行的

5) SingleThreadScheduledExecutor

SingleThreadScheduledExecutor，它实际和第三种 ScheduledThreadPool 线程池非常相似，它只是 ScheduledThreadPool 的一个特例，内部只有一个线程，如源码所示

6) ForkJoinPool

ForkJoinPool，这个线程池是在 JDK 7 加入的，它的名字 ForkJoin 也描述了它的执行机制，主要用法和之前的线程池是相同的，也是把任务交给线程池去执行，线程池中也有任务队列来存放任务。但是 ForkJoinPool 线程池和之前的线程池有两点非常大的不同之处。

1) 第一点 它非常适合执行可以产生子任务的任务

2) 不同之处在于内部结构，之前的线程池所有的线程共用一个队列，但 ForkJoinPool 线程池中每个线程都有自己独立的任务队列

线程池名称

描述

FixedThreadPool

核心线程数与最大线程数相同

SingleThreadExecutor

一个线程的线程池

CachedThreadPool

核心线程为0，最大线程数为Integer. MAX_VALUE

ScheduledThreadPool

指定核心线程数的定时线程池

SingleThreadScheduledExecutor

单例的定时线程池

ForkJoinPool

JDK 7 新加入的一种线程池

3.4.5 线程池常用的阻塞队列有哪些

工作队列workQueue

该线程池中的任务队列：维护着等待执行的Runnable对象

当所有的核心线程都在干活时，新添加的任务会被添加到这个队列中等待处理，如果队列满了，则新建非核心线程执行任务

常用的workQueue类型：

1.SynchronousQueue

这个队列接收到任务的时候，会直接提交给线程处理，而不保留它，如果所有线程都在工作怎么办？那就新建一个线程来处理这个任务！所以为了保证不出现<线程数达到了maximumPoolSize而不能新建线程>的错误，使用这个类型队列的时候，maximumPoolSize一般指定成Integer.MAX_VALUE，即无限大

2 . LinkedBlockingQueue

这个队列接收到任务的时候，如果当前线程数小于核心线程数，则新建线程(核心线程)处理任务；如果当前线程数等于核心线程数，则进入队列等待。由于这个队列没有最大值限制，即所有超过核心线程数的任务都将被添加到队列中，这也就导致了maximumPoolSize的设定失效，因为总线程数永远不会超过corePoolSize

3.ArrayBlockingQueue

可以限定队列的长度，接收到任务的时候，如果没有达到corePoolSize的值，则新建线程(核心线程)执行任务，如果达到了，则入队等候，如果队列已满，则新建线程(非核心线程)执行任务，又如果总线程数到了maximumPoolSize，并且队列也满了，则发生错误

4.DelayQueue

队列内元素必须实现Delayed接口，这就意味着你传进去的任务必须先实现Delayed接口。这个队列接收到任务时，首先先入队，只有达到了指定的延时时间，才会执行任务

3.4.6 为什么不应该自动创建线程池？

FixedThreadPool

通过往构造函数中传参，创建了一个核心线程数和最大线程数相等的线程池，它们的数量也就是我们传入的参数，这里的重点是使用的队列是容量没有上限的 LinkedBlockingQueue，如果我们对任务的处理速度比较慢，那么随着请求的增多，队列中堆积的任务也会越来越多，最终大量堆积的任务会占用大量内存，并发生 OOM ，也就是OutOfMemoryError，这几乎会影响到整个程序，会造成很严重的后果。

SingleThreadExecutor

newSingleThreadExecutor 和 newFixedThreadPool 的原理是一样的，只不过把核心线程数和最大线程数都直接设置成了 1，但是任务队列仍是无界的 LinkedBlockingQueue，所以也会导致同样的问题，也就是当任务堆积时，可能会占用大量的内存并导致 OOM。

CachedThreadPool

这里的 CachedThreadPool 和前面两种线程池不一样的地方在于任务队列使用的是 SynchronousQueue，SynchronousQueue 本身并不存储任务，而是对任务直接进行转发，这本身是没有问题的，但你会发现构造函数的第二个参数被设置成了 Integer.MAX_VALUE，这个参数的含义是最大线程数，所以由于 CachedThreadPool 并不限制线程的数量，当任务数量特别多的时候，就可能会导致创建非常多的线程，最终超过了操作系统的上限而无法创建新线程，或者导致内存不足。

ScheduledThreadPool 和 SingleThreadScheduledExecutor

它采用的任务队列是 DelayedWorkQueue，这是一个延迟队列，同时也是一个无界队列，所以和 LinkedBlockingQueue 一样，如果队列中存放过多的任务，就可能导致 OOM。

这几种自动创建的线程池都存在风险，相比较而言，我们自己手动创建会更好，因为我们可以更加明确线程池的运行规则，不仅可以选择适合自己的线程数量，更可以在必要的时候拒绝新任务的提交，避免资源耗尽的风险。

3.4.7 合适的线程数量是多少？CPU 核心数和线程数的关系？

CPU 密集型任务

首先，我们来看 CPU 密集型任务，比如加密、解密、压缩、计算等一系列需要大量耗费 CPU 资源的任务。对于这样的任务最佳的线程数为 CPU 核心数的 1~2 倍，如果设置过多的线程数，实际上并不会起到很好的效果。此时假设我们设置的线程数量是 CPU 核心数的 2 倍以上，因为计算任务非常重，会占用大量的 CPU 资源，所以这时 CPU 的每个核心工作基本都是满负荷的，而我们又设置了过多的线程，每个线程都想去利用 CPU 资源来执行自己的任务，这就会造成不必要的上下文切换，此时线程数的增多并没有让性能提升，反而由于线程数量过多会导致性能下降

针对这种情况，最好还要同时考虑在同一台机器上还有哪些其他会占用过多 CPU 资源的程序在运行，然后对资源使用做整体的平衡

耗时 IO 型任务

比如数据库、文件的读写，网络通信等任务，这种任务的特点是并不会特别消耗 CPU 资源，但是 IO 操作很耗时，总体会占用比较多的时间。对于这种任务最大线程数一般会大于 CPU 核心数很多倍，因为 IO 读写速度相比于 CPU 的速度而言是比较慢的，如果我们设置过少的线程数，就可能导致 CPU 资源的浪费。而如果我们设置更多的线程数，那么当一部分线程正在等待 IO 的时候，它们此时并不需要 CPU 来计算，那么另外的线程便可以利用 CPU 去执行其他的任务，互不影响，这样的话在任务队列中等待的任务就会减少，可以更好地利用资源

《Java并发编程实战》的作者 Brain Goetz 推荐的计算方法

线程数 = CPU 核心数 *（1+平均等待时间/平均工作时间）

通过这个公式，我们可以计算出一个合理的线程数量，如果任务的平均等待时间长，线程数就随之增加，而如果平均工作时间长，也就是对于我们上面的 CPU 密集型任务，线程数就随之减少

太少的线程数会使得程序整体性能降低，而过多的线程也会消耗内存等其他资源，所以如果想要更准确的话，可以进行压测，监控 JVM 的线程情况以及 CPU 的负载情况，根据实际情况衡量应该创建的线程数，合理并充分利用资源

结论

线程的平均工作时间所占比例越高，就需要越少的线程

线程的平均等待时间所占比例越高，就需要越多的线程

针对不同的程序，进行对应的实际测试就可以得到最合适的选择

3.4.8 如何根据实际需要，定制自己的线程池？

如上

3.4.9 如何正确关闭线程池？shutdown 和 shutdownNow 的区别？

首先，我们创建一个线程数固定为 10 的线程池，并且往线程池中提交 100 个任务，如代码所示

ExecutorService service = Executors.newFixedThreadPool(10);for (int i = 0; i < 100; i++) { service.execute(new Task());}

如果现在我们想关闭该线程池该如何做呢？

void shutdown;
boolean isShutdown;
boolean isTerminated;
boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException;
List<Runnable> shutdownNow;
shutdown()

它可以安全地关闭一个线程池，调用 shutdown() 方法之后线程池并不是立刻就被关闭，因为这时线程池中可能还有很多任务正在被执行，或是任务队列中有大量正在等待被执行的任务，调用 shutdown() 方法后线程池会在执行完正在执行的任务和队列中等待的任务后才彻底关闭。但这并不代表 shutdown() 操作是没有任何效果的，调用 shutdown() 方法后如果还有新的任务被提交，线程池则会根据拒绝策略直接拒绝后续新提交的任务

isShutdown()

它可以返回 true 或者 false 来判断线程池是否已经开始了关闭工作，也就是是否执行了 shutdown 或者 shutdownNow 方法。这里需要注意，如果调用 isShutdown() 方法的返回的结果为 true 并不代表线程池此时已经彻底关闭了，这仅仅代表线程池开始了关闭的流程，也就是说，此时可能线程池中依然有线程在执行任务，队列里也可能有等待被执行的任务

isTerminated()

这个方法可以检测线程池是否真正“终结”了，这不仅代表线程池已关闭，同时代表线程池中的所有任务都已经都执行完毕了，因为我们刚才说过，调用 shutdown 方法之后，线程池会继续执行里面未完成的任务，不仅包括线程正在执行的任务，还包括正在任务队列中等待的任务。比如此时已经调用了 shutdown 方法，但是有一个线程依然在执行任务，那么此时调用 isShutdown 方法返回的是 true ，而调用 isTerminated 方法返回的便是 false ，因为线程池中还有任务正在在被执行，线程池并没有真正“终结”。直到所有任务都执行完毕了，调用 isTerminated() 方法才会返回 true，这表示线程池已关闭并且线程池内部是空的，所有剩余的任务都执行完毕了

awaitTermination()

它本身并不是用来关闭线程池的，而是主要用来判断线程池状态的。比如我们给 awaitTermination 方法传入的参数是 10 秒，那么它就会陷入 10 秒钟的等待，直到发生以下三种情况之一

等待期间（包括进入等待状态之前）线程池已关闭并且所有已提交的任务（包括正在执行的和队列中等待的）都执行完毕，相当于线程池已经“终结”了，方法便会返回 true

等待超时时间到后，第一种线程池“终结”的情况始终未发生，方法返回 false

等待期间线程被中断，方法会抛出 InterruptedException 异常

调用 awaitTermination 方法后当前线程会尝试等待一段指定的时间，如果在等待时间内，线程池已关闭并且内部的任务都执行完毕了，也就是说线程池真正“终结”了，那么方法就返回 true，否则超时返回 fasle，我们则可以根据 awaitTermination() 返回的布尔值来判断下一步应该执行的操作

shutdownNow()

也是 5 种方法里功能最强大的，它与第一种 shutdown 方法不同之处在于名字中多了一个单词 Now，也就是表示立刻关闭的意思。在执行 shutdownNow 方法之后，首先会给所有线程池中的线程发送 interrupt 中断信号，尝试中断这些任务的执行，然后会将任务队列中正在等待的所有任务转移到一个 List 中并返回，我们可以根据返回的任务 List 来进行一些补救的操作，例如记录在案并在后期重试

shutdownNow() 的源码如下所示：

public List<Runnable> shutdownNow() { List<Runnable> tasks;final ReentrantLock mainLock = this.mainLock;mainLock.lock();try { checkShutdownAccess();advanceRunState(STOP);interruptWorkers();tasks = drainQueue();} finally { mainLock.unlock();} tryTerminate();return tasks;}

可以看到源码中有一行 interruptWorkers() 代码，这行代码会让每一个已经启动的线程都中断，这样线程就可以在执行任务期间检测到中断信号并进行相应的处理，提前结束任务。这里需要注意的是，由于 Java 中不推荐强行停止线程的机制的限制，即便我们调用了 shutdownNow 方法，如果被中断的线程对于中断信号不理不睬，那么依然有可能导致任务不会停止。可见我们在开发中落地最佳实践是很重要的，我们自己编写的线程应当具有响应中断信号的能力，应当利用中断信号来协同工作

我们就可以根据自己的业务需要，选择合适的方法来停止线程池，比如通常我们可以用 shutdown() 方法来关闭，这样可以让

3.4.10 线程池实现“线程复用”的原理

执行任务先调用的是t.start()方法，这个t是个Thread对象，而这个Thread对象则是从Worker对象里获得的，在Worker在做初始化时就会赋值Thread，同时Worker初始化Thread对象时又是以自己作为参数来完成，而Worker对象又是个实现了Runnable接口的类，那Worker对象就肯定有自己的run方法，所以t.start()方法真正意义上调用的是Worker对象中重写的run方法，而这个Worker对象中的run方法里没有所谓的本地start方法，JVM自然不会再创建新的线程，而是把它当普通方法一样执行。再加上whlie循环体，这样就做到了Worker对象新建的线程始终都会在一个大循环里，而这个线程会反复的获取任务，接着执行任务，直到任务都执行完毕，这就是线程池实现“线程复用”的原理。

3.5 什么是线程安全相关问题

3.5.1 什么叫线程安全？servlet是线程安全吗?

线程安全 就是多线程在运行期间不会产生不符合常规的数据。

同样在多线程访问同一代码，不会产生不确定的结果

线程安全首先呢他的是多线程，至少是2个。因为一个线程那肯定是线程安全的。就你自己一个线程执行没有人给你争用资源。你是在串行执行，不会出现不确定结果。 如果有多个线程 那问题可就多了。比如一个 ArrayList 类，在添加一个元素的时候，它可能会有两步来完成：

1. 在 Items[Size] 的位置存放此元素；

2. 增大 Size 的值。

线程A完成第一步时，被CPU暂停了。此时Size值还是原来的值线程B并不知情，又跑到线程A刚才放元素的位置又放了一遍，然后Size+1。紧接着A也被唤醒了，也去Size+1 这时候Size = 2了，但是只有一个元素。虽然放了两次放到了同样的位置上覆盖了。

Servlet是线程不安全的。

3.5.2 同步有几种实现方法？

同步有两种方法 分别是synchronized wait与notify

3.5.3 volatile有什么用？能否用一句话说明下volatile的应用场景？

Volatile 的作用就是多线程使用同一个变量时，每次都去主内存去读。保障了数据的实时性。 应用场景就是多线程 操作同一个变量。

3.5.4 请说明下java的内存模型及其工作流程。

Java线程之间的通信采用的是过共享内存模型，这里提到的共享内存模型指的就是Java内存模型(简称JMM)，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存(main memory)中，每个线程都有一个私有的本地内存(local memory)，本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。

3.5.5 何解决多线程之间线程安全问题？

使用多线程之间同步synchronized或使用锁(lock).因为多线程将可能会发生数据冲突问题（线程不安全问题）,只能让当前一个线程进行执行。代码执行完成后释放锁，然后才能让线程进行执行。这样的话就可以解决线程不安全问题。而多线程同步之后，当多个线程共享同一个资源，不会受到其他线程的干扰。

3.5.6 为什么会有线程安全问题？

以计算机来说，在计算机系统中，系统资源分配的单位被称为进程，而在同一个进程计算机允许多个线程并发执行，并且多个线程能够共享进程范围内的资源，如内存地址等。但是，当多个线程当多个线程并发访问同一个内存地址并且内存地址保存的值是可变的时候就有可能会发生线程安全问题，因此需要内存数据共享机制来保证线程安全问题。

引起线程安全问题的原因：

线程安全问题都是由全局变量及静态变量引起的。

若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则的话就可能影响线程安全。

3.5.7 多线程死锁？

死锁的原因

当一个线程永远地持有一个锁，并且其他线程都尝试去获得这个锁时，那么它们将永远被阻塞

避免死锁的方式

既然可能产生死锁，那么接下来，讲一下如何避免死锁。

1、让程序每次至多只能获得一个锁。当然，在多线程环境下，这种情况通常并不现实

2、设计时考虑清楚锁的顺序，尽量减少嵌在的加锁交互数量

3、既然死锁的产生是两个线程无限等待对方持有的锁，那么只要等待时间有个上限不就好了。当然synchronized不具备这个功能，但是我们可以使用Lock类中的tryLock方法去尝试获取锁，这个方法可以指定一个超时时限，在等待超过该时限之后变回返回一个失败信息

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

线程安全的定义

在谈synchronized关键字之前，菜鸡想先谈一谈线程安全的概念。相信绝大多数小伙伴都听说过“线程安全”这一概念，想要了解一个概念，最好的方式就是从其定义出发。

线程安全的定义(引自《Java并发编程实战》)如下：当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的。

根据以上描述，结合大佬们的经验，我们可以总结出非线程安全的条件：

多线程环境。

共享资源。

没有保证原子性、可见性和有序性。

容易对这三个条件做出说明。首先，如果是单线程的环境下，我们自然不必关系非线程安全的问题。其次，如果是没有线程间共享的资源，也就不会出现线程安全的问题。最后，如果保证了操作的原子性、可见性和有序性，也就不会有线程安全的问题。事实上，Java内存模型就是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征来建立的。

实现线程安全的方式

实现线程安全的方式主要有三种：

互斥同步：例如，基于synchronized关键字或者Lock接口实现同步。

非阻塞同步：例如，基于CAS操作的原子类，但CAS操作会出现ABA问题，如果需要解决ABA问题，可以引入版本号，也可以改用其他同步方案。

无同步方案：例如，通过ThreadLocal实现线程本地存储。

本文关注的重点是JVM对原子性、可见性、有序性所作的支持：

关于原子性，保证原子性的方式有很多种，除了操作本身是原子性之外，还可以采用一些原子类保证原子性，可以通过加锁的方式，或者无锁算法保证原子性。本文主要讲述的是利用synchronized关键字保证原子性。

关于可见性，Java主要有三个关键字可以保证可见性，一个是我们之前讲过的volatile关键字，另一个是final关键字，还有一个就是本文提到的synchronized关键字。

关于有序性，Java主要有两个关键字可以保证有序性，一个是我们之前讲过的volatile关键字，另一个就是本文提到的synchronized关键字。

synchronized关键字

synchronized关键字是Java中实现互斥同步最基本的手段，它是一种悲观锁，是一种可重入锁(通过锁计数器是否为0判定对象持有或者释放锁的状态)。

synchronized关键字的工作原理：

在同步语句块时，synchronized关键字经过编译之后，会在同步块的前后形成monitorenter和monitorexit两个字节码指令，代表对象实例或者Class对象作为线程要持有的锁。

在修饰方法时，synchronized关键字经过编译之后，会生成ACC_SYNCHRONIZED标识，代表该方法是一个同步方法。

synchronized关键字的不足及改进：

synchronized是Java语言的一个重量级操作，因为线程的阻塞与唤醒会涉及到操作系统用户态与核心态之间的转换，会消耗大量的时间。

从JDK1.5升级到JDK1.6后，HotSpot虚拟机开发团队实现了各种锁优化技术，例如，适应性自旋锁，锁消除，锁膨胀，轻量级锁，偏向锁等优化，从而实现线程间更高效的数据共享和解决竞争问题。

3.5.9 怎么使用 synchronized 关键字

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

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

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

public class Singleton {private volatile static Singleton uniqueInstance;private Singleton() {}public static Singleton getUniqueInstance() {//先判断对象是否已经实例过，没有实例化过才进入加锁代码if (uniqueInstance == null) {//类对象加锁synchronized (Singleton.class) {if (uniqueInstance == null) {uniqueInstance = new Singleton();}}}return uniqueInstance;}
}

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

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

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

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

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

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

①偏向锁

引入偏向锁的目的和引入轻量级锁的目的很像，他们都是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。但是不同是：轻量级锁在无竞争的情况下使用 CAS 操作去代替使用互斥量。而偏向锁在无竞争的情况下会把整个同步都消除掉。

偏向锁的“偏”就是偏心的偏，它的意思是会偏向于第一个获得它的线程，如果在接下来的执行中，该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步！关于偏向锁的原理可以查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。

但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。

② 轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)。轻量级锁不是为了代替重量级锁，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗，因为使用轻量级锁时，不需要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操作。 关于轻量级锁的加锁和解锁的原理可以查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。

轻量级锁能够提升程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥操作的开销。但如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因此在有锁竞争的情况下，轻量级锁比传统的重量级锁更慢！如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁！

③ 自旋锁和自适应自旋

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。

互斥同步对性能最大的影响就是阻塞的实现，因为挂起线程/恢复线程的操作都需要转入内核态中完成（用户态转换到内核态会耗费时间）。

一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。 所以，虚拟机的开发团队就这样去考虑：“我们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。为了让一个线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就叫做自旋。

百度百科对自旋锁的解释：

何谓自旋锁？它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。

自旋锁在 JDK1.6 之前其实就已经引入了，不过是默认关闭的，需要通过--XX:+UseSpinning参数来开启。JDK1.6及1.6之后，就改为默认开启的了。需要注意的是：自旋等待不能完全替代阻塞，因为它还是要占用处理器时间。如果锁被占用的时间短，那么效果当然就很好了！反之，相反！自旋等待的时间必须要有限度。如果自旋超过了限定次数任然没有获得锁，就应该挂起线程。自旋次数的默认值是10次，用户可以修改--XX:PreBlockSpin来更改。

另外,在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得越来越“聪明”了。

④ 锁消除

锁消除理解起来很简单，它指的就是虚拟机即使编译器在运行时，如果检测到那些共享数据不可能存在竞争，那么就执行锁消除。锁消除可以节省毫无意义的请求锁的时间。

⑤ 锁粗化

原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小，——直在共享数据的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待线程也能尽快拿到锁。

大部分情况下，上面的原则都是没有问题的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗。

3.5.12 谈谈synchronized和ReenTrantLock 的区别

① 两者都是可重入锁

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

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

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

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

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

ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。

ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。 ReenTrantLock默认情况是非公平的，可以通过 ReenTrantLock类的ReentrantLock(boolean fair)构造方法来制定是否是公平的。

synchronized关键字与wait()和notify/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知” ，这个功能非常重要，而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。

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

④ 性能已不是选择标准

在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操作。

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

synchronized关键字和volatile关键字比较

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

2 多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞

3 volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字两者都能保证。

4 volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。

3.6 ThreadLocal详解相关问题

3.6.1 ThreadLocal 是什么？

ThreadLocal 是线程本地存储，在每个线程中都创建了一个 ThreadLocalMap 对象，每个线程可以访问自己内部 ThreadLocalMap 对象内的 value。

3.6.2 ThreadLocal 工作原理是什么？

首先，在Thread类中定义了一个threadLocals，它是ThreadLocal.ThreadLocalMap对象的引用,默认值是null。ThreadLocal.ThreadLocalMap对象表示了一个以开放地址形式的散列表。当我们在线程的run方法中第一次调用ThreadLocal对象的get方法时，会为当前线程创建一个ThreadLocalMap对象。也就是每个线程都各自有一张独立的散列表，以ThreadLocal对象作为散列表的key，set方法中的值作为value（第一次调用get方法时，以initialValue方法的返回值作为value）。显然我们可以定义多个ThreadLocal对象，而我们一般将ThreadLocal对象定义为static类型或者外部类中。上面所表达的意思就是，相同的key在不同的散列表中的值必然是独立的，每个线程都是在各自的散列表中执行操作。

3.6.3 ThreadLocal 如何解决 Hash 冲突？

什么是散列

散列表(hash table)我们平时也叫它哈希表或者Hash表，它用的是数组支持按照下标随机访问数据的特性，所以散列表其实就是数组的一种扩展，由数组演化而来。可以说，没有数组就没有散列表。

比如我们有100件商品,编号没有规律的4位数字,现在我们想要通过编号快速获取商品信息，如何做呢?我们可以将这100件商品信息放到数组里，通过 商品编号%100这样的方式得到一个值,值为1的商品放到数组中下标为1的位置，值为2的商品，我们放到数组中下标为2的位置。以此类推，编号为K的选手放到数组中下标为K的位置。因为商品编号通过散列函数(编号%100)跟数据下标一一对应，所以但我们需要查询编号为x的商品信息的时候,我们使用同样的方式，将编号转换为数组下标，就可以从对应的数组下标的位置取出数据。

这就是散列的典型思想。

我们通过上面的例子可以得出这样规律：散列表用的就是数组支持按照下标随机访问的时候，时间复杂度是 O(1) 的特性。通过散列函数(商品编号%100)把元素的键值映

射为下标，然后将数据存储在数组中对应下标的位置。当我们按照键值查询元素时，我们用同样的散列函数，将键值转化数组下标，从对应的数组下标的位置取

数据。

开放寻址

一说到散列(或者叫做hash表),大家更熟悉的是HashMap或者LinkedHashMap,而今天的主角是ThreadLocalMap,它是ThreadLocal中的一个内部类。分析ThreadLocal源码的时候不可能绕过它。

由于哈希表使用了数组,无论hash函数如何设计都无可避免存在hash冲突。上面的例子如果两件商品的id分别是1001和1101,那么他们的数据就会就会被放到数组的同一个位置，出现了冲突

鸽巢原理，又名狄利克雷抽屉原理、鸽笼原理。其中一种简单的表述法为：若有n个笼子和n+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少2只鸽子

ThreadLocalMap作为hash表的一种实现方式,它是使用什么方式来解决冲突的呢?它使用了开放寻址法来解决这个问题。

元素插入

开放寻址法的核心是如果出现了散列冲突，就重新探测一个空闲位置，将其插入。当我们往散列表中插入数据时，如果某个数据经过散列函数散列之后，存储位置已经被占用了，我们就从当前位置开始，依次往后查找，看是否有空闲位置，直到找到为止。

image

从图中可以看出，散列表的大小为 10 ，该元素 x 插入散列表之前，已经 6 个元素插入到散列表中。 x 经过 Hash 算法之后，被散列到位置下标为 7 的位置,但是这个位置已经有数据了，所以就产生了冲突。于是我们就顺序地往后一个一个找，看有没有空闲的位置，遍历到尾部都没有找到空闲的位置，于是我们再从表头开始找，直到找到空闲位置 2 ，于是将其插入到这个位置。

元素查找

在散列表中查找元素的过程有点儿类似插入过程。我们通过散列函数求出要查找元素的键值对应的散列值，然后比较数组中下标为散列值的元素和要查找的元素。如果相等，则说明就是我们要找的元素；否则就顺序往后依次查找。如果遍历到数组中的空闲位置，还没有找到，就说明要查找的元素并没有在散列表中。

元素删除

ThreadLocalMap跟数组一样，不仅支持插入、查找操作，还支持删除操作。对于使用线性探测法解决冲突的散列表，删除操作稍微有些特别。我们不能单纯地把要删除的元素设置为空。

还记得我们刚讲的查找操作吗？在查找的时候，一旦我们通过线性探测方法，找到一个空闲位置，我们就可以认定散列表中不存在这个数据。但是，如果这个空闲位置是我们后来删除的，就会导致原来的查找算法失效。本来存在的数据，会被认定为不存在。这个问题如何解决呢？

我们可以在删除元素之后,将之后不为null的数据rehash，这样就不会影响查询的逻辑

另一种方法是:可以将删除的元素，特殊标记为 deleted 。当线性探测查找的时候，遇到标记为 deleted 的空间，并不是停下来，而是继续往下探测

rehash

这里解释下rehash的过程:当删除元素8的时候，先把下标为8的值设置为null,然后将其后面不为空的数组元素rehash。比如8后面的元素是9,其原本应该的位置(9%10=9)就在9所以不移动。下一个元素是19,应该在下标为9的位置,但是已经被占用了,所以就找下一个空闲的位置，下标为3的位置是空闲的，放入tab[3]。接着下一个元素1就在tab[1]不移动，

元素7的位置在tab[7]，因为已经被占用，放入下一个空闲位置tab[8]。下一个元素仍然是19,这里由于tab[9]已经被占用，所以放入下一个空闲位置tab[0]。接着最后一个元素4位置就在tab[4],所以不移动。元素4的下一个位置为空，整个rehash过程结束。

装载因子

你可能已经发现了，线性探测法其实存在很大问题。当散列表中插入的数据越来越多时，散列冲突发生的可能性就会越来越大，空闲位置会越来越少，线性探测的时间就会越来越久。极端情况下，我们可能需要探测整个散列表，所以最坏情况下的时间复杂度为 O(n) 。同理，在删除和查找时，也有可能会线性探测整张散列表，才能找到要查找或者删除的数据。

不管采用哪种探测方法，hash函数设计得在合理,当散列表中空闲位置不多的时候，散列冲突的概率就会大大提高。为了尽可能保证散列表的操作效率，一般情况下，我们会尽可能保证散列表中有一定比例的空闲槽位。我们用装载因子(load factor)来表示空位的多少。

装载因子的计算公式是：散列表的装载因子=填入表中的元素个数/散列表的长度 装载因子越大，说明空闲位置越少，冲突越多，散列表的性能会下降。

3.6.4 ThreadLocal 的内存泄露是怎么回事？

在线程池中线程的存活时间太长，往往都是和程序同生共死的，这样 Thread 持有的 ThreadLocalMap 一直都不会被回收，再加上 ThreadLocalMap 中的 Entry 对 ThreadLocal 是弱引用（WeakReference），所以只要 ThreadLocal 结束了自己的生命周期是可以被回收掉的。

Entry 中的 Value 是被 Entry 强引用的，即便 value 的生命周期结束了，value 也是无法被回收的，导致内存泄露。

3.6.5 为何 ThreadLocalMap 的 key 是弱引用？

ThreadLocalMap是用来存放对象的，在一次线程的执行栈中，存放数据后方便我们在任意的地方取得我们想要的值而不被其他线程干扰。ThreadLocalMap本身并没有为外界提供取出和存放数据的API，我们所能获得数据的方式只有通过ThreadLocal类提供的API来间接的从ThreadLocalMap取出数据，所以，当我们用不了key（ThreadLocal对象）的API也就无法从ThreadLocalMap里取出指定的数据。

A对象被回收了，这些get和set方法也访问不到了，也就没法从ThreadLocalMap里取出数据了。没法利用API取出数据，那这个Entry对象还有用吗？？所以最好的方法是在A对象被回收后，系统自动回收对应的Entry对象，但是让Entry对象或其中的value对象做为弱引用都是非常不合理的。所以，让key（threadLocal对象）为弱引用，自动被垃圾回收，key就变为null了，下次，我们就可以通过Entry不为null，而key为null来判断该Entry对象该被清理掉了。

3.7 进程与线程间通信方式相关问题

3.7.1 进程间通信的方式有哪些？线程间通讯方式有哪些？

一，进程中的通信方式

管道( pipe )：

管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。

有名管道 (namedpipe) ：

有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。

信号量(semophore ) ：

信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。

消息队列( messagequeue ) ：

消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。

信号 (sinal ) ：

信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。

共享内存(shared memory ) ：

共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。

套接字(socket ) ：

套接口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同设备及其间的进程通信。

二，线程中的通讯方式

锁机制：包括互斥锁、条件变量、读写锁

互斥锁提供了以排他方式防止数据结构被并发修改的方法。

读写锁允许多个线程同时读共享数据，而对写操作是互斥的。

条件变量可以以原子的方式阻塞进程，直到某个特定条件为真为止。对条件的测试是在互斥锁的保护下 进行的。条件变量始终与互斥锁一起使用。

信号量机制(Semaphore)：包括无名线程信号量和命名线程信号量

信号机制(Signal)：类似进程间的信号处理 线程间的通信目的主要是用于线程同步，所以线程没有像进程通信中的用于数据交换的通信机制。

3.7.2 join方法的原理？

Join方法实现是通过wait（小提示：Object 提供的方法）。 当main线程调用t.join时候，main线程会获得线程对象t的锁（wait 意味着拿到该对象的锁),调用该对象的wait(等待时间)，直到该对象唤醒main线程 ，比如退出后。这就意味着main 线程调用t.join时，必须能够拿到线程t对象的锁。

3.7.3 notify和notifyall有什么区别？

如果线程调用了对象的 wait()方法，那么线程便会处于该对象的等待池中，等待池中的线程不会去竞争该对象的锁。

当有线程调用了对象的 notifyAll()方法（唤醒所有 wait 线程）或 notify()方法（只随机唤醒一个 wait 线程），被唤醒的的线程便会进入该对象的锁池中，锁池中的线程会去竞争该对象锁。也就是说，调用了notify后只要一个线程会由等待池进入锁池，而notifyAll会将该对象等待池内的所有线程移动到锁池中，等待锁竞争

优先级高的线程竞争到对象锁的概率大，假若某线程没有竞争到该对象锁，它还会留在锁池中，唯有线程再次调用 wait()方法，它才会重新回到等待池中。而竞争到对象锁的线程则继续往下执行，直到执行完了 synchronized 代码块，它会释放掉该对象锁，这时锁池中的线程会继续竞争该对象锁。

3.7.4 为什么wait方法要写在while循环里面而不是if呢？

因为当一个等待线程醒来的时候，可能互斥量被其他的线程（notifyAll 后可能又改变了互斥量的值，或者线程的假醒来 ，或者 等等）又改变了，所以需要重复判断条件。

3.7.5 在 Java 的并发编程中，什么是等待-通知机制？它是怎么实现的？

首先，设想这样一种场景：一个线程的执行需要满足某些条件，当条件不满足时就通过一个循环不断尝试，直到条件满足。

这个场景下存在一个明显的缺点，就是线程不断地尝试获取所需的条件，这个循环的过程会白白浪费CPU资源，降低系统性能。

等待-通知机制是一种优化策略，其核心思想就是：当线程所需条件不满足时，就阻塞该线程，之后当条件满足时再通知线程，以此提高硬件资源的利用率

Java 中的实现

在 Java 中实现等待-通知机制，一种经典的做法是使用 synchronized + wait() + notify() / notifyAll()

3.8 volalite详解相关问题

3.8.1 讲讲什么是JMM

JMM就是Java内存模型(java memory model)。因为在不同的硬件生产商和不同的操作系统下，内存的访问有一定的差异，所以会造成相同的代码运行在不同的系统上会出现各种问题。所以java内存模型(JMM)屏蔽掉各种硬件和操作系统的内存访问差异，以实现让java程序在各种平台下都能达到一致的并发效果。

Java内存模型规定所有的变量都存储在主内存中，包括实例变量，静态变量，但是不包括局部变量和方法参数。每个线程都有自己的工作内存，线程的工作内存保存了该线程用到的变量和主内存的副本拷贝，线程对变量的操作都在工作内存中进行。线程不能直接读写主内存中的变量。

不同的线程之间也无法访问对方工作内存中的变量。线程之间变量值的传递均需要通过主内存来完成。

如果听起来抽象的话，我可以画张图给你看看，会直观一点：

3.8.2 八种内存交互操作

规定了8种原子操作：

1.lock（锁定）：将主内存中的变量锁定，为一个线程所独占

2.unlock（解锁）：将lock加的锁定解除，此时其它的线程可以有机会访问此变量

3.read（读取）：作用于主存变量，将主存中的变量读到工作内存当中

4.load（载入）：作用于工作内存变量，将read读取的值保存到工作内存中的变量副本中

5.use（使用）：作用于工作内存变量，将值传递给线程的代码执行引擎

6.assign（赋值）：作用于工作内存变量，将执行引擎处理返回的值重新赋值给变量副本

7.store（存储）：作用于工作内存变量，将变量副本的值传送到主内存中

8.write（写入）：作用于主内存变量，将store传送过来的值写入到主内存的共享变量中

3.8.3 volatile为啥不能保证原子性

修改volatile变量分为四步：

1）读取volatile变量到local

2）修改变量值

3）local值写回

4）插入内存屏障，即lock指令，让其他线程可见

这样就很容易看出来，前三步都是不安全的，取值和写回之间，不能保证没有其他线程修改。原子性需要锁来保证。

3.8.4 volatile怎么禁止指令重排序

Volatile实现禁止指令重排优化，从而避免了多线程环境下程序出现乱序执行的现象

首先了解一个概念，内存屏障（Memory Barrier）又称内存栅栏，是一个CPU指令，它的作用有两个：

1 保证特定操作的顺序

2 保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）

也就是过在Volatile的写 和 读的时候，加入屏障，防止出现指令重排的

3.8.5 什么是指令重排序

java中的指令重排序是：

重排序通常是编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。

重排序分为两类：编译期重排序和运行期重排序，分别对应编译时和运行时环境

3.8.6 如何保证原子性

三种方式

1 synchronized同步代码块

2 cas原子类工具

3 lock锁机制

3.8.7 long和double的原子性

  1. 对于64位的long和double，如果没有被volatile修饰，那么对其操作可以不是原子的。在操作的时候，可以分成两步，每次对32位操作。
  2. 如果使用volatile修饰long和double，那么其读写都是原子操作
  3. 对于64位的引用地址的读写，都是原子操作
  4. 在实现JVM时，可以自由选择是否把读写long和double作为原子操作
  5. 推荐JVM实现为原子操作

3.8.8 Volatile在双重检查加锁的单例中的应用

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

第一个注意点：getInstance方法中第一个判空条件，逻辑上是可以去除的，去除之后并不影响单例的正确性，但是去除之后效率低。因为去掉之后，不管instance是否已经初始化，都会进行synchronized操作，而synchronized是一个重操作消耗性能。加上之后，如果已经初始化直接返回结果，不会进行synchronized操作。

第二个注意点：加上synchronized是为了防止多个线程同时调用getInstance方法时，各初始化instance一遍的并发问题。

第三个注意点：getInstance方法中的第二个判空条件是不可以去除，如果去除了，并且刚好有两个线程a和b都通过了第一个判空条件。此时假设a先获得锁，进入synchronized的代码块，初始化instance，a释放锁。接着b获得锁，进入synchronized的代码块，也直接初始化instance，instance被初始化多遍不符合单例模式的要求~。加上第二个判空条件之后，b获得锁进入synchronized的代码块，此时instance不为空，不执行初始化操作。

第四个注意点：instance的声明有一个voliate关键字，如果不用该关键字，有可能会出现异常。因为instance = new Test();并不是一个原子操作，会被编译成三条指令，根据 JSR-133 定义的 JMM，synchronized 的加锁和解锁之间能够有确定的顺序，但是多个线程下 synchronized 之前的非空判断之间并不能保证顺序。所以需要用 volatile 来保证非空判断之间的 happens-before 关系。

3.8.9 volatile的使用场景

volatile的适用场景

模式 #1：状态标志

也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

模式 #2：一次性安全发布（one-time safe publication）

在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。

这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象。如下面介绍的单例模式。

模式 #3：独立观察（independent observation）

安全使用 volatile 的另一种简单模式是：定期 “发布” 观察结果供程序内部使用。【例如】假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。

使用该模式的另一种应用程序就是收集程序的统计信息。

3.9 synchronized详解相关问题

3.9.1 synchronized关键字的底层原理

通过对.class文件反编译可以发现：

同步方法通过ACC_SYNCHRONIZED修饰。

代码块同步使用monitorenter和monitorexit两个指令实现。

虽然两者实现细节不同，但其实本质上都是JVM基于进入和退出Monitor对象来实现同步，JVM的要求如下：

monitorenter指令会在编译后插入到同步代码块的开始位置，而monitorexit则会插入到方法结束和异常处。

每个对象都有一个monitor与之关联，且当一个monitor被持有之后，他会处于锁定状态。

线程执行到monitorenter时，会尝试获取对象对应monitor的所有权。

在获取锁时，如果对象没被锁定，或者当前线程已经拥有了该对象的锁（可重进入，不会锁死自己），将锁计数器加一，执行monitorexit时，锁计数器减一，计数为零则锁释放。

获取对象锁失败，则当前线程陷入阻塞，直到对象锁被另外一个线程释放。

3.9.2 synchronized 是公平锁还是非公平锁

是非公平锁

当一个线程想获取锁时，先试图插队，如果占用锁的线程释放了锁，下一个线程还没来得及拿锁，那么当前线程就可以直接获得锁；如果锁正在被其它线程占用，则排队，排队的

时候就不能再试图获得锁了，只能等到前面所有线程都执行完才能获得锁。

3.9.3 Java中除了synchronized 还有别的锁吗？

lock锁

3.9.4 synchronized关键字的三种使用

synchronized关键字的三种使用

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

修饰静态方法: 也就是给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 class 的锁。

注意：静态成员不属于任何一个实例对象，是类成员！因此，一个线程A调用一个实例对象的非静态synchronized方法，一个线程B调用这个实例对象的所属类的静态synchronized方法，是被允许的。

因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。

修饰代码块 ：给括号内配置的对象加锁。synchronized(this|object) 表示进入同步代码库前要获得给定对象的锁。synchronized(类.class) 表示进入同步代码前要获得 当前 class 的锁。

3.10 synchronized优化相关问题

3.10.1 Synchronized 为啥要进行优化

Synchronized是基于底层操作系统的 Mutex Lock 实现的，每次获取锁和释放锁的操作都会带来用户态和内核态的切换，从而增加系统性能开销

3.10.2 锁优化的方式

减少锁持有时间

减少锁粒度

锁分离

锁粗化

锁消除

3.10.3 锁的状态种类

目前锁状态一种有四种，从级别由低到高依次是：无锁、偏向锁，轻量级锁，重量级锁。

锁

优点

缺点

适用场景

偏向锁

加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距

如果线程间存在锁竞争，会带来额外的锁撤销的消耗

适用于只有一个线程访问同步块场景

轻量级锁

竞争的线程不会阻塞，提高了程序的响应速度

如果始终得不到索竞争的线程，使用自旋会消耗CPU

追求响应速度，同步块执行速度非常快

重量级锁

线程竞争不使用自旋，不会消耗CPU

线程阻塞，响应时间缓慢

追求吞吐量，同步块执行速度较慢

3.11 Lock接口详解相关问题

3.11.1 ReentrantReadWriteLock类和ReentrantLock类的区别

当有很多线程都从某个数据结构中读取数据而很少有线程对其进行修改时，后者就很有用了。在这种情况下，允许读取器线程共享访问是合适的。当然，写入器线程依然必须是互斥访问的

下面是使用读/写锁的必要步骤：

(1) 创建一个ReentrantReadWriteLock对象

 private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

(2)抽取读锁和写锁：

private Lock readLock = rwl.readLock();//得到一个可被多个读操作共用的读锁，但它会排斥所有写操作
private Lock writeLock = rwl.writeLock();//得到一个写锁，它会排斥所有其他的读操作和写操作

(3) 对所有访问者加读锁

public double getTotalBalance(){readLock.lock();try{...};finally{readLock.unlock();}
}

对所有修改者加写锁

public void transfer(){writeLock.lock();try{...};finally{writeLock.unlock();}
}

3.11.2 Lock与synchronized的区别

1. Lock的加锁和解锁都是由java代码配合native方法（调用操作系统的相关方法）实现的，而synchronize的加锁和解锁的过程是由JVM管理的

2. 当一个线程使用synchronize获取锁时，若锁被其他线程占用着，那么当前只能被阻塞，直到成功获取锁。而Lock则提供超时锁和可中断等更加灵活的方式，在未能获取锁的 条件下提供一种退出的机制。

3. 一个锁内部可以有多个Condition实例，即有多路条件队列，而synchronize只有一路条件队列；同样Condition也提供灵活的阻塞方式，在未获得通知之前可以通过中断线程以 及设置等待时限等方式退出条件队列。

4. synchronize对线程的同步仅提供独占模式，而Lock即可以提供独占模式，也可以提供共享模式

3.12 锁的介绍相关问题

3.12.1 什么是乐观锁和悲观锁？

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

3.12.2 锁的分类

乐观锁/悲观锁

独享锁/共享锁

互斥锁/读写锁

可重入锁

公平锁/非公平锁

分段锁

偏向锁/轻量级锁/重量级锁

自旋锁

3.12.3 乐观锁的实现方式

版本号机制

一般是在数据表中加上版本号字段 version，表示数据被修改的次数。当数据被修改时，这个字段值会加1。

举个简单的例子：假设帐户信息表中有一个 version 字段，当前值为 1 ，而当前帐户的余额（ balance ）为 100 。

操作员 A 此时准备将其读出（ version=1 ），并从其帐户余额中扣除 50（ 100-50 ）；

操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 20 （ 100-20 ）；

操作员 A 完成修改工作，将数据版本号加1（ version=2 ），连同帐户扣除后余额（ balance=50 ），提交到数据库完成更新；

操作员 B 完成了操作，也将版本号加1（ version=2 ）试图向数据库提交数据（ balance=80 ），但此时比对数据库记录版本发现，操作员 B 提交的数据版本号为 2 ，数据库记录的当前版本也为 2 ，不满足 “提交版本必须大于记录当前版本才能执行更新“ 的乐观锁策略。

因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧数据修改，最终造成覆盖操作员 A 操作结果的可能。

CAS 算法

即 compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS 算法涉及到三个操作数：

需要读写的内存值 V

进行比较的值 A

拟写入的新值 B

当且仅当 V 的值等于 A 时，CAS 通过原子方式用新值 B 来更新 V 的值，否则不会执行任何操作（比较和替换是一个 native 原子操作）。一般情况下，这是一个自旋操作，即不断的重试。

3.12.4 重入锁和不可重入锁

定义

可重入锁 ：当线程获取某个锁后，还可以继续获取它，可以递归调用，而不会发生死锁；例如 ReentrantLock、synchronized

不可重入锁：与可重入相反，获取锁后不能重复获取，否则会死锁（自己锁自己）

3.13 死锁相关问题

3.13.1 什么是死锁？

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程

3.13.2 产生死锁的原因？

竞争资源引起进程死锁

当系统中供多个进程共享的资源如打印机、公用队列的等，其数目不足以满足诸进程的需要时，会引起诸进程对资源的竞争而产生死锁。

可剥夺资源和不可剥夺资源

系统中的资源可以分为两类，一类是可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺。例如，优先权高的进程可以剥夺优先权低的进程的处理机。又如，内存区可由存储器管理程序，把一个进程从一个存储区移到另一个存储区，此即剥夺了该进程原来占有的存储区，甚至可将一进程从内存调到外存上，可见，CPU和主存均属于可剥夺性资源。另一类资源是不可剥夺资源，当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机、打印机等。

竞争不可剥夺资源

在系统中所配置的不可剥夺资源，由于它们的数量不能满足诸进程运行的需要，会使进程在运行过程中，因争夺这些资源而陷于僵局。例如，系统中只有一台打印机R1和一台磁带机R2，可供进程P1和P2共享。假定PI已占用了打印机R1，P2已占用了磁带机R2，若P2继续要求打印机R1，P2将阻塞；P1若又要求磁带机，P1也将阻塞。于是，在P1和P2之间就形成了僵局，两个进程都在等待对方释放自己所需要的资源，但是它们又都因不能继续获得自己所需要的资源而不能继续推进，从而也不能释放自己所占有的资源，以致进入死锁状态。

竞争临时资源

上面所说的打印机资源属于可顺序重复使用型资源，称为永久资源。还有一种所谓的临时资源，这是指由一个进程产生，被另一个进程使用，短时间后便无用的资源，故也称为消耗性资源，如硬件中断、信号、消息、缓冲区内的消息等，它也可能引起死锁。例如，SI，S2，S3是临时性资源，进程P1产生消息S1，又要求从P3接收消息S3；进程P3产生消息S3，又要求从进程P2处接收消息S2；进程P2产生消息S2，又要求从P1处接收产生的消息S1。如果消息通信按如下顺序进行：

P1: ···Relese（S1）；Request（S3）； ···

P2: ···Relese（S2）；Request（S1）； ···

P3: ···Relese（S3）；Request（S2）； ···

并不可能发生死锁。但若改成下述的运行顺序：

P1: ···Request（S3）；Relese（S1）；···

P2: ···Request（S1）；Relese（S2）； ···

P3: ···Request（S2）；Relese（S3）； ···

则可能发生死锁。

2.进程推进顺序不当引起死锁

由于进程在运行中具有异步性特征，这可能使P1和P2两个进程按下述两种顺序向前推进。

1） 进程推进顺序合法

当进程P1和P2并发执行时，如果按照下述顺序推进：P1：Request（R1）； P1：Request（R2）； P1: Relese（R1）；P1: Relese（R2）； P2：Request（R2）； P2：Request（R1）； P2: Relese（R2）；P2: Relese（R1）；这两个进程便可顺利完成，这种不会引起进程死锁的推进顺序是合法的。

2） 进程推进顺序非法

若P1保持了资源R1,P2保持了资源R2，系统处于不安全状态，因为这两个进程再向前推进，便可能发生死锁。例如，当P1运行到P1：Request（R2）时，将因R2已被P2占用而阻塞；当P2运行到P2：Request（R1）时，也将因R1已被P1占用而阻塞，于是发生进程死锁。

3.13.3 死锁产生的4个必要条件？

死锁产生的四个必要条件

1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用

2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。

3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。

4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

3.13.4 解决死锁的基本方法

在系统中已经出现死锁后，应该及时检测到死锁的发生，并采取适当的措施来解除死锁。

死锁预防

这是一种较简单和直观的事先预防的方法。方法是通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或者几个，来预防发生死锁。预防死锁是一种较易实现的方法，已被广泛使用。但是由于所施加的限制条件往往太严格，可能会导致系统资源利用率和系统吞吐量降低。

死锁避免

系统对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源；如果分配后系统可能发生死锁，则不予分配，否则予以分配。这是一种保证系统不进入死锁状态的动态策略。

死锁检测和解除

先检测：这种方法并不须事先采取任何限制性措施，也不必检查系统是否已经进入不安全区，此方法允许系统在运行过程中发生死锁。但可通过系统所设置的检测机构，及时地检测出死锁的发生，并精确地确定与死锁有关的进程和资源。检测方法包括定时检测、效率低时检测、进程等待时检测等。

然后解除死锁：采取适当措施，从系统中将已发生的死锁清除掉。

这是与检测死锁相配套的一种措施。当检测到系统中已发生死锁时，须将进程从死锁状态中解脱出来。常用的实施方法是撤销或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程，使之转为就绪状态，以继续运行。死锁的检测和解除措施，有可能使系统获得较好的资源利用率和吞吐量，但在实现上难度也最大。

如果我们在死锁检查时发现了死锁情况，那么就要努力消除死锁，使系统从死锁状态中恢复过来。消除死锁的几种方式：

1 最简单、最常用的方法就是进行系统的重新启动，不过这种方法代价很大，它意味着在这之前所有的进程已经完成的计算工作都将付之东流，包括参与死锁的那些进程，以及未参与死锁的进程；

2 撤消进程，剥夺资源。终止参与死锁的进程，收回它们占有的资源，从而解除死锁。这时又分两种情况：一次性撤消参与死锁的全部进程，剥夺全部资源；或者逐步撤消参与死锁的进程，逐步收回死锁进程占有的资源。一般来说，选择逐步撤消的进程时要按照一定的原则进行，目的是撤消那些代价最小的进程，比如按进程的优先级确定进程的代价；考虑进程运行时的代价和与此进程相关的外部作业的代价等因素；

3 进程回退策略，即让参与死锁的进程回退到没有发生死锁前某一点处，并由此点处继续执行，以求再次执行时不再发生死锁。虽然这是个较理想的办法，但是操作起来系统开销极大，要有堆栈这样的机构记录进程的每一步变化，以便今后的回退，有时这是无法做到的。

3.13.5 死锁与饥饿

死锁和饥饿的主要区别是什么？

饥饿与死锁有一定联系：二者都是由于竞争资源而引起的，但又有明显差别，主要表现在如下几个方面：

(1)从进程状态考虑，死锁进程都处于等待状态，忙式等待(处于运行或就绪状态)的进程并非处于等待状态，但却可能被饿死；

(2)死锁进程等待永远不会被释放的资源，饿死进程等待会被释放但却不会分配给自己的资源，表现为等待时限没有上界(排队等待或忙式等待)；

(3)死锁一定发生了循环等待，而饿死则不然。这也表明通过资源分配图可以检测死锁存在与否，但却不能检测是否有进程饿死；

(4)死锁一定涉及多个进程，而饥饿或被饿死的进程可能只有一个。

饥饿和饿死与资源分配策略有关，因而防止饥饿与饿死可从公平性考虑，确保所有进程不被忽视，如FCFS分配算法。

常见出现的问题会在后面的文章讨论，一起学习的朋友可以点点关注，会持续更新，文章有帮助的话可以长按点赞有惊喜！！！文章比较长，大家可以贤 收藏、转发后看，有什么补充可以在下面评论，谢谢大家！

bat 等大厂常问的Java多线程面试题，3万字解析相关推荐

  1. Java继承_30道最常问的Java基础面试题

    30道最常问的Java基础面试题 1. 面向对象和面向过程的区别面向过程优点: 性能比面向对象高,因为类调用时需要实例化,开销比较大,比较消耗资源;比如单片机.嵌入式开发.Linux/Unix等一般采 ...

  2. BATJ都爱问的Java多线程面试题整理

    今天给大家总结一下,面试中出镜率很高的几个多线程面试题,希望对大家学习和面试都能有所帮助.备注:文中的代码自己实现一遍的话效果会更佳哦! 一.面试中关于 synchronized 关键字的 5 连击 ...

  3. 30道最常问的Java基础面试题

    1. 面向对象和面向过程的区别 面向过程 优点: 性能比面向对象高,因为类调用时需要实例化,开销比较大,比较消耗资源;比如单片机.嵌入式开发.Linux/Unix等一般采用面向过程开发,性能是最重要的 ...

  4. 2022最新Spring相关大厂常问技术面试题大全 —— 金三银四好时机

    Spring相关大厂常问面试题 1. 什么是 Spring 框架? 2. 列举一些重要的Spring模块? 3. @RestController 与 @Controller 的区别 4. 谈谈自己对于 ...

  5. java中高级面试_中高级面试常问：Java面向对象设计的六大原则

    这篇文章主要讲的是面向对象设计中,我们应该遵循的六大原则.只有掌握了这些原则,我们才能更好的理解设计模式.我们接下来要介绍以下6个内容.单一职责原则--SRP 开闭原则--OCP 里式替换原则--LS ...

  6. 史上最全 Java 多线程面试题及答案

    这篇文章主要是对多线程的问题进行总结的,因此罗列了40个多线程的问题. 这些多线程的问题,有些来源于各大网站.有些来源于自己的思考.可能有些问题网上有.可能有些问题对应的答案也有.也可能有些各位网友也 ...

  7. 15个顶级Java多线程面试题及回答（高级java工程师）

    Java 线程面试问题 在任何Java面试当中多线程和并发方面的问题都是必不可少的一部分.如果你想获得任何股票投资银行的前台资讯职位,那么你应该准备很多关于多线程的问题.在投资银行业务中多线程和并发是 ...

  8. 15个顶级Java多线程面试题及答案

    转载自  15个顶级Java多线程面试题及答案 在任何Java面试当中多线程和并发方面的问题都是必不可少的一部分.如果你想获得更多职位,那么你应该准备很多关于多线程的问题. 他们会问面试者很多令人混淆 ...

  9. 15个Java多线程面试题

    2019独角兽企业重金招聘Python工程师标准>>> 在任何Java面试当中多线程和并发方面的问题都是必不可少的一部分.如果你想获得任何股票投资银行的前台资讯职位,那么你应该准备很 ...

最新文章

  1. 图灵11月书讯：大约在冬季
  2. itchat 动态注册
  3. @async 没有异步_扒一扒VueCLI3.0中Axios异步请求同步化
  4. JSTL标签库中fmt标签，日期，数字的格式化
  5. CompletableFuture 异步编程
  6. Nginx 架构详解
  7. java定义int函数_Java自定义函数的四种类型
  8. request.form 和 Request.QueryString 区别
  9. 近场动力学python_科学网—近动力学最新上线的文章快报：2018年7月 - 韩非的博文...
  10. 三维空间点到直线的距离C++实现
  11. 业务太忙，真的是没时间搞自动化理由吗？
  12. 21中科大软件学院上岸经验帖
  13. STM32F103C8T6个人学习之路01-芯片介绍
  14. 由标明空子树的先序遍历序列创建二叉树
  15. 2.中继镜（增距镜）详解
  16. 美化上传文件框(上传图片框)
  17. APP同过ESP8266与51单片机通信
  18. 2017年2月历史文章汇总
  19. 产品 电信nb接口调用_基于NB-IoT平台数据透传模式的应用接入平台设计方法与流程...
  20. JDK1.8安装教程

热门文章

  1. PHP之mb_stripos使用
  2. 硬件先生---第 3 部分：电源知识（Power)-3.2-DC-DC
  3. 设计 Pastebin.com (或者 Bit.ly)
  4. 云计算时代 Java 程序员面临的挑战和机遇
  5. 《夜深人静写算法》数论篇 - (17) 扩展欧拉定理
  6. 辛丑年丙申月癸卯日|数与运算
  7. 【WPF】后台代码实现绑定ComboBox的SelectedItem功能
  8. 组织学图像弱监督腺体分割的在线简易示例挖掘
  9. Python自动录入ERP系统数据
  10. 微服务解决方案 -- Mybatis-Plus + Redis缓存，如何不太优雅的使用Redis缓存