为什么我们要学习并发编程？
从上面互联网公司的招聘需求可以看到，大厂的Java岗的并发编程能力属于标配。
而在非大厂的公司，并发编程能力也是面试的极大加分项，而工作时善用并发编程则可以极大提升程序员在公司的技术话语权
为什么开发中需要并发编程
从阿里的岗位JD其实就能看出来，并发编程和性能优化是密切相关的，使用并发编程可以做到：
(1)加快响应用户的时间
比如我们经常用的迅雷下载,都喜欢多开几个线程去下载,谁都不愿意用一个线程去下载,为什么呢?答案很简单,就是多个线程下载快啊。
我们在做程序开发的时候更应该如此,特别是我们做互联网项目,网页的响应时间若提升1s,如果流量大的话,就能增加不少转换量。做过高性能web前端调优的都知道,要将静态资源地址用两三个子域名去加载,为什么?因为每多一个子域名,浏览器在加载你的页面的时候就会多开几个线程去加载你的页面资源,提升网站的响应速度。
(2)使你的代码模块化,异步化,简单化
例如我们实现电商系统，下订单和给用户发送短信、邮件就可以进行拆分，将给用户发送短信、邮件这两个步骤独立为单独的模块，并交给其他线程去执行。这样既增加了异步的操作，提升了系统性能，又使程序模块化,清晰化和简单化。
多线程应用开发的好处还有很多,大家在日后的代码编写过程中可以慢慢体会它的魅力。
(3)充分利用CPU的资源
目前市面上没有CPU的内核不是多核的，比如这台机器
多核下如果还是使用单线程的技术做思路明显就out了，无法充分利用CPU的多核特点。如果设计一个多线程的程序的话,那它就可以同时在多个CPU的多个核的多个线程上跑，可以充分地利用CPU,减少CPU的空闲时间,发挥它的运算能力,提高并发量。
就像我们平时坐地铁一样,很多人坐长线地铁的时候都在认真看书,而不是为了坐地铁而坐地铁,到家了再去看书,这样你的时间就相当于有了两倍。这就是为什么有些人时间很充裕,而有些人老是说没时间的一个原因,工作也是这样,有的时候可以并发地去做几件事情,充分利用我们的时间,CPU也是一样，也要充分利用。
当然有同学会有疑问，单核CPU呢？单核CPU一样可以利用到并发编程的好处吗？当然可以，用我们平时常用的QQ之类的聊天程序来举例，当我们用QQ聊天时，其实程序要做好几件事，比如：接受我们的键盘输入，把输入的信息通过网络发给对方，接受对方通过网络发来的信息，把对方的信息显示在屏幕上，很多的时候，这些事情是可以同时发生的。如果程序不能利用并发编程同时处理，我们和对方的通话就只能一问一答的方式进行了。
基础概念
进程和线程
进程
我们常听说的是应用程序，也就是app，由指令和数据组成。但是当我们不运行一个具体的app时，这些应用程序就是放在磁盘（也包括U盘、远程网络存储等等）上的一些二进制的代码。一旦我们运行这些应用程序，指令要运行，数据要读写，就必须将指令加载至 CPU，数据加载至内存。在指令运行过程中还需要用到磁盘、网络等设备，从这种角度来说，进程就是用来加载指令、管理内存、管理 IO的。
当一个程序被运行，从磁盘加载这个程序的代码至内存，这时就开启了一个进程。
进程就可以视为程序的一个实例。大部分程序可以同时运行多个实例进程（例如记事本、画图、浏览器 等），也有的程序只能启动一个实例进程（例如网易云音乐、360 安全卫士等）。显然,程序是死的、静态的,进程是活的、动态的。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就是处于运行状态下的操作系统本身,用户进程就是所有由你启动的进程。
站在操作系统的角度，进程是程序运行资源分配（以内存为主）的最小单位。
线程
一个机器中肯定会运行很多的程序，CPU又是有限的，怎么让有限的CPU运行这么多程序呢？就需要一种机制在程序之间进行协调，也就所谓CPU调度。线程则是CPU调度的最小单位。
线程必须依赖于进程而存在，线程是进程中的一个实体，是CPU调度和分派的基本单位，它是比进程更小的、能独立运行的基本单位。线程自己基本上不拥有系统资源,，只拥有在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。一个进程可以拥有多个线程，一个线程必须有一个父进程。线程，有时也被称为轻量级进程(Lightweight Process，LWP），早期Linux的线程实现几乎就是复用的进程，后来才独立出自己的API。
Java线程的无处不在
Java中不管任何程序都必须启动一个main函数的主线程; Java Web开发里面的定时任务、定时器、JSP和 Servlet、异步消息处理机制,远程访问接口RM等,任何一个监听事件，onclick的触发事件等都离不开线程和并发的知识。
CPU核心数和线程数的关系
前面说过，目前主流CPU都是多核的，线程是CPU调度的最小单位。同一时刻，一个CPU核心只能运行一个线程，也就是CPU内核和同时运行的线程数是1:1的关系，也就是说8核CPU同时可以执行8个线程的代码。但 Intel引入超线程技术后，产生了逻辑处理器的概念，使核心数与线程数形成1:2的关系。在我们前面的Windows任务管理器贴图就能看出来，内核数是6而逻辑处理器数是12。
在Java中提供了Runtime.getRuntime().availableProcessors()，可以让我们获取当前的CPU核心数，注意这个核心数指的是逻辑处理器数。
获得当前的CPU核心数在并发编程中很重要，并发编程下的性能优化往往和CPU核心数密切相关。
上下文切换（Context switch）
既然操作系统要在多个进程（线程）之间进行调度，而每个线程在使用CPU时总是要使用CPU中的资源，比如CPU寄存器和程序计数器。这就意味着，操作系统要保证线程在调度前后的正常执行，所以，操作系统中就有上下文切换的概念，它是指CPU(中央处理单元)从一个进程或线程到另一个进程或线程的切换。
上下文是CPU寄存器和程序计数器在任何时间点的内容。
寄存器是CPU内部的一小部分非常快的内存(相对于CPU内部的缓存和CPU外部较慢的RAM主内存)，它通过提供对常用值的快速访问来加快计算机程序的执行。
程序计数器是一种专门的寄存器，它指示CPU在其指令序列中的位置，并保存着正在执行的指令的地址或下一条要执行的指令的地址，这取决于具体的系统。
上下文切换可以更详细地描述为内核(即操作系统的核心)对CPU上的进程(包括线程)执行以下活动:
1. 暂停一个进程的处理，并将该进程的CPU状态(即上下文)存储在内存中的某个地方
2. 从内存中获取下一个进程的上下文，并在CPU的寄存器中恢复它
3. 返回到程序计数器指示的位置(即返回到进程被中断的代码行)以恢复进程。
从数据来说，以程序员的角度来看， 是方法调用过程中的各种局部的变量与资源； 以线程的角度来看， 是方法的调用栈中存储的各类信息。
引发上下文切换的原因一般包括：线程、进程切换、系统调用等等。上下文切换通常是计算密集型的，因为涉及一系列数据在各种寄存器、 缓存中的来回拷贝。就CPU时间而言，一次上下文切换大概需要5000~20000个时钟周期，相对一个简单指令几个乃至十几个左右的执行时钟周期，可以看出这个成本的巨大。
并行和并发
我们举个例子,如果有条高速公路A上面并排有8条车道,那么最大的并行车辆就是8辆此条高速公路A同时并排行走的车辆小于等于8辆的时候,车辆就可以并行运行。CPU也是这个原理,一个CPU相当于一个高速公路A,核心数或者线程数就相当于并排可以通行的车道;而多个CPU就相当于并排有多条高速公路,而每个高速公路并排有多个车道。
当谈论并发的时候一定要加个单位时间,也就是说单位时间内并发量是多少？离开了单位时间其实是没有意义的。
综合来说：
并发Concurrent:指应用能够交替执行不同的任务,比如单CPU核心下执行多线程并非是同时执行多个任务,如果你开两个线程执行,就是在你几乎不可能察觉到的速度不断去切换这两个任务,已达到"同时执行效果",其实并不是的,只是计算机的速度太快,我们无法察觉到而已.
并行Parallel:指应用能够同时执行不同的任务,例:吃饭的时候可以边吃饭边打电话,这两件事情可以同时执行
线程的状态/生命周期
Java中线程的状态分为6种：
1. 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。
2. 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。
线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。
3. 阻塞(BLOCKED)：表示线程阻塞于锁。
4. 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。
5. 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。
6. 终止(TERMINATED)：表示该线程已经执行完毕。
状态之间的变迁如下图所示
掌握这些状态可以让我们在进行Java程序调优时可以提供很大的帮助。
线程的优先级和调度
yield()方法：使当前线程让出CPU占有权，但让出的时间是不可设定的。也不会释放锁资源。同时执行yield()的线程有可能在进入到就绪状态后会被操作系统再次选中马上又被执行。
比如，ConcurrentHashMap#initTable 方法中就使用了这个方法，
这是因为ConcurrentHashMap中可能被多个线程同时初始化table，但是其实这个时候只允许一个线程进行初始化操作，其他的线程就需要被阻塞或等待，但是初始化操作其实很快，这里Doug Lea大师为了避免阻塞或者等待这些操作引发的上下文切换等等开销，就让其他不执行初始化操作的线程干脆执行yield()方法，以让出CPU执行权，让执行初始化操作的线程可以更快的执行完成。
wait()/notify()/notifyAll()：后面会单独讲述
线程的优先级
在Java线程中，通过一个整型成员变量priority来控制优先级，优先级的范围从1~10，在线程构建的时候可以通过setPriority(int)方法来修改优先级，默认优先级是5，优先级高的线程分配时间片的数量要多于优先级低的线程。
设置线程优先级时，针对频繁阻塞（休眠或者I/O操作）的线程需要设置较高优先级，而偏重计算（需要较多CPU时间或者偏运算）的线程则设置较低的优先级，确保处理器不会被独占。在不同的JVM以及操作系统上，线程规划会存在差异，有些操作系统甚至会忽略对线程优先级的设定。
线程的调度
线程调度是指系统为线程分配CPU使用权的过程，主要调度方式有两种：
协同式线程调度(Cooperative Threads-Scheduling)
抢占式线程调度(Preemptive Threads-Scheduling)
使用协同式线程调度的多线程系统，线程执行的时间由线程本身来控制，线程把自己的工作执行完之后，要主动通知系统切换到另外一个线程上。使用协同式线程调度的最大好处是实现简单，由于线程要把自己的事情做完后才会通知系统进行线程切换，所以没有线程同步的问题，但是坏处也很明显，如果一个线程出了问题，则程序就会一直阻塞。
使用抢占式线程调度的多线程系统，每个线程执行的时间以及是否切换都由系统决定。在这种情况下，线程的执行时间不可控，所以不会有「一个线程导致整个进程阻塞」的问题出现。
Java线程调度就是抢占式调度，为什么？后面会分析。
在Java中，Thread.yield()可以让出CPU执行时间，但是对于获取执行时间，线程本身是没有办法的。对于获取CPU执行时间，线程唯一可以使用的手段是设置线程优先级，Java设置了10个级别的程序优先级，当两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。
线程和协程
为什么Java线程调度是抢占式调度？这需要我们了解Java中线程的实现模式。
我们已经知道线程其实是操作系统层面的实体，Java中的线程怎么和操作系统层面对应起来呢？
任何语言实现线程主要有三种方式：使用内核线程实现（1:1实现)，使用用户线程实现(1:N实现），使用用户线程加轻量级进程混合实现(N:M实现）。
内核线程实现
使用内核线程实现的方式也被称为1： 1实现。 内核线程（Kernel-Level Thread， KLT） 就是直接由操作系统内核（Kernel， 下称内核） 支持的线程， 这种线程由内核来完成线程切换， 内核通过操纵调度器（Scheduler） 对线程进行调度， 并负责将线程的任务映射到各个处理器上。
由于内核线程的支持，每个线程都成为一个独立的调度单元，即使其中某一个在系统调用中被阻塞了，也不会影响整个进程继续工作，相关的调度工作也不需要额外考虑，已经由操作系统处理了。
局限性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、 析构及同步，都需要进行系统调用。而系统调用的代价相对较高， 需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换。其次，每个语言层面的线程都需要有一个内核线程的支持，因此要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持的线程数量是有限的。
辨析线程和协程
用户线程实现
严格意义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。 如果程序实现得当， 这种线程不需要切换到内核态， 因此操作可以是非常快速且低消耗的， 也能够支持规模更大的线程数量， 部分高性能数据库中的多线程就是由用户线程实现的。
用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援， 所有的线程操作都需要由用户程序自己去处理。线程的创建、销毁、切换和调度都是用户必须考虑的问题，而且由于操作系统只把处理器资源分配到进程，那诸如“阻塞如何处理”“多处理器系统中如何将线程映射到其他处理器上”这类问题解决起来将会异常困难， 甚至有些是不可能实现的。 因为使用用户线程实现的程序通常都比较复杂，所以一般的应用程序都不倾向使用用户线程。Java语言曾经使用过用户线程，最终又放弃了。 但是近年来许多新的、以高并发为卖点的编程语言又普遍支持了用户线程，譬如Golang。
混合实现
线程除了依赖内核线程实现和完全由用户程序自己实现之外， 还有一种将内核线程与用户线程一起使用的实现方式， 被称为N：M实现。 在这种混合实现下， 既存在用户线程， 也存在内核线程。
用户线程还是完全建立在用户空间中， 因此用户线程的创建、 切换、 析构等操作依然廉价， 并且可以支持大规模的用户线程并发。
同样又可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过内核线程来完成。在这种混合模式中， 用户线程与轻量级进程的数量比是不定的，是N：M的关系。
Java线程的实现
J Java线程在早期的Classic虚拟机上（JDK 1.2以前），是用户线程实现的， 但从JDK 1.3起， 主流商用Java虚拟机的线程模型普遍都被替换为基于操作系统原生线程模型来实现，即采用1： 1的线程模型。
以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构， 所以HotSpot自己是不会去干涉线程调度的，全权交给底下的操作系统去处理。
所以，这就是我们说Java线程调度是抢占式调度的原因。而且Java中的线程优先级是通过映射到操作系统的原生线程上实现的，所以线程的调度最终取决于操作系统，操作系统中线程的优先级有时并不能和Java中的一一对应，所以Java优先级并不是特别靠谱。
协程
出现的原因
随着互联网行业的发展，目前内核线程实现在很多场景已经有点不适宜了。比如，互联网服务架构在处理一次对外部业务请求的响应， 往往需要分布在不同机器上的大量服务共同协作来实现，，也就是我们常说的微服务，这种服务细分的架构在减少单个服务复杂度、 增加复用性的同时， 也不可避免地增加了服务的数量， 缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算， 这样组合多个服务的总耗时才不会太长；也要求每一个服务提供者都要能同时处理数量更庞大的请求， 这样才不会出现请求由于某个服务被阻塞而出现等待。
Java目前的并发编程机制就与上述架构趋势产生了一些矛盾，1：1的内核线程模型是如今Java虚拟机线程实现的主流选择， 但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也很有限。 以前处理一个请求可以允许花费很长时间在单体应用中，具有这种线程切换的成本也是无伤大雅的， 但现在在每个请求本身的执行时间变得很短、 数量变得很多的前提下，用户本身的业务线程切换的开销甚至可能会接近用于计算本身的开销，这就会造成严重的浪费。
另外我们常见的Java Web服务器，比如Tomcat的线程池的容量通常在几十个到两百之间， 当把数以百万计的请求往线程池里面灌时， 系统即使能处理得过来，但其中的切换损耗也是相当可观的。
这样的话，对Java语言来说，用户线程的重新引入成为了解决上述问题一个非常可行的方案。
其次，Go语言等支持用户线程等新型语言给Java带来了巨大的压力，也使得Java引入用户线程成为了一个绕不开的话题。
协程简介
为什么用户线程又被称为协程呢？我们知道，内核线程的切换开销是来自于保护和恢复现场的成本， 那如果改为采用用户线程， 这部分开销就能够省略掉吗？ 答案还是“不能”。 但是，一旦把保护、恢复现场及调度的工作从操作系统交到程序员手上，则可以通过很多手段来缩减这些开销。
由于最初多数的用户线程是被设计成协同式调度（Cooperative Scheduling） 的，所以它有了一个别名——“协程”（Coroutine） 完整地做调用栈的保护、恢复工作，所以今天也被称为“有栈协程”（Stackfull Coroutine）。
协程的主要优势是轻量， 无论是有栈协程还是无栈协程， 都要比传统内核线程要轻量得多。如果进行量化的话， 那么如果不显式设置，则在64位Linux上HotSpot的线程栈容量默认是1MB， 此外内核数据结构（Kernel Data Structures） 还会额外消耗16KB内存。与之相对的， 一个协程的栈通常在几百个字节到几KB之间， 所以Java虚拟机里线程池容量达到两百就已经不算小了， 而很多支持协程的应用中， 同时并存的协程数量可数以十万计。
协程当然也有它的局限， 需要在应用层面实现的内容（调用栈、 调度器这些）特别多，同时因为协程基本上是协同式调度，则协同式调度的缺点自然在协程上也存在。
总的来说，协程机制适用于被阻塞的，且需要大量并发的场景（网络io），不适合大量计算的场景，因为协程提供规模(更高的吞吐量)，而不是速度(更低的延迟)。
纤程-Java中的协程
在JVM的实现上，以HotSpot为例，协程的实现会有些额外的限制，Java调用栈跟本地调用栈是做在一起的。 如果在协程中调用了本地方法， 还能否正常切换协程而不影响整个线程？ 另外， 如果协程中遇传统的线程同步措施会怎样？ 譬如Kotlin提供的协程实现， 一旦遭遇synchronize关键字， 那挂起来的仍将是整个线程。
所以Java开发组就Java中协程的实现也做了很多努力，OpenJDK在2018年创建了Loom项目，这是Java的官方解决方案， 并用了“纤程（Fiber）”这个名字。
Loom项目背后的意图是重新提供对用户线程的支持， 但这些新功能不是为了取代当前基于操作系统的线程实现， 而是会有两个并发编程模型在Java虚拟机中并存， 可以在程序中同时使用。 新模型有意地保持了与目前线程模型相似的API设计， 它们甚至可以拥有一个共同的基类， 这样现有的代码就不需要为了使用纤程而进行过多改动， 甚至不需要知道背后采用了哪个并发编程模型。
根据Loom团队在2018年公布的他们对Jetty基于纤程改造后的测试结果， 同样在5000QPS的压力下， 以容量为400的线程池的传统模式和每个请求配以一个纤程的新并发处理模式进行对比， 前者的请求响应延迟在10000至20000毫秒之间， 而后者的延迟普遍在200毫秒以下，
目前Java中比较出名的协程库是Quasar[ˈkweɪzɑː(r)]（Loom项目的Leader就是Quasar的作者Ron Pressler）， Quasar的实现原理是字节码注入，在字节码层面对当前被调用函数中的所有局部变量进行保存和恢复。这种不依赖Java虚拟机的现场保护虽然能够工作，但影响性能。
Quasar实战
本实战的代码是单独的项目quasar。
Quasar的使用其实并不复杂，首先引入Maven依赖
在具体的业务场景上，我们模拟调用某个远程的服务，假设远程服务处理耗时需要1S，使用休眠1S来代替。为了比较，用多线程和协程分别调用这个服务10000次，来看看两者所需的耗时。
Quasar的：
线程的：
从代码层面来看，两者的代码高度相似，忽略两者的公共部分，代码不同的地方也就2、3行。
其中的Fiber就是Quasar为我们提供的协程相关的类，可以类比为Java中的Thread类。
其他的CountDownLatch（闭锁，线程的某种协调工具类）、Executors.newCachedThreadPool（线程池）是并发编程后面的课程将要学习的知识。StopWatch是Spring的一个工具类，一个简单的秒表工具，可以计时指定代码段的运行时间以及汇总这个运行时间。
上面的代码现在看不懂不要紧，随着后面并发编程知识的继续学习，这些代码是很容易理解的，现在只要知道这些代码的业务意义即可：调用远程服务10000次，每次耗时1S，然后统计总耗时。
在执行Quasar的代码前，还需要配置VM参数（Quasar的实现原理是字节码注入，所以，在运行应用前，需要配置好quasar-core的java agent地址）
-javaagent:D:\Maven\repository\co\paralleluniverse\quasar-core\0.7.9\quasar-core-0.7.9.jar
自己运行前记得修改为本机的Maven仓库路径
看看执行的结果：
可以看到性能的提升还是非常明显的。而且上面多线程编程时，并没有指定线程池的大小，在实际开发中是绝不允许的。一般我们会设置一个固定大小的线程池，因为线程资源是宝贵，线程多了费内存还会带来线程切换的开销。上面的场景在设置200个固定大小线程池时（Executors.newFixedThreadPool(200)），在本机的测试结果达到了50多秒，几乎是数量级的增加。
由这个结果也可以看到协程在需要处理大量IO的情况下非常具有优势，基于固定的几个线程调度，可以轻松实现百万级的协程处理，而且内存消耗非常平稳。
更多Quasar的使用方法和技巧，请大家自行挖掘和学习。
JDK19的虚拟线程
2022年9月22日，JDK19（非LTS版本）正式发布，引入了协程，并称为轻量级虚拟线程。但是这个特性目前还是预览版，还不能引入生成环境。因为环境所限，本课程不提供实际的范例，只讲述基本用法和原理。
要使用的话，需要通过
使用javac --release 19 --enable-preview XXX.java编译程序，并使用 java --enable-preview XXX 运行该程序
在具体使用上和原来的Thread API差别不大：java.lang.Thread.Builder，可以创建和启动虚拟线程，例如：
Thread thread = Thread.ofVirtual().name("duke").unstarted(runnable);
// Thread.ofPlatform() 则创建传统意义的实际
或者
Thread.startVirtualThread(Runnable)
并通过Executors.newVirtualThreadPerTaskExecutor()提供了虚拟线程池功能。
在具体实现上，虚拟线程当然是基于用户线程模式实现的，JDK 的调度程序不直接将虚拟线程分配给处理器，而是将虚拟线程分配给实际线程，是一个 M: N 调度，具体的调度程序由已有的ForkJoinPool提供支持。
但是虚拟线程不是协同调度的，JDK的虚拟线程调度程序通过将虚拟线程挂载到平台线程上来分配要在平台线程上执行的虚拟线程。在运行一些代码之后，虚拟线程可以从其载体卸载。此时平台线程是空闲的，因此调度程序可以在其上挂载不同的虚拟线程，从而使其再次成为载体。
通常，当虚拟线程阻塞 I/O 或 JDK中的其他阻塞操作(如BlockingQueue.take ())时，它将卸载。当阻塞操作准备完成时(例如，在套接字上已经接收到字节) ，它将虚拟线程提交回调度程序，调度程序将在运营商上挂载虚拟线程以恢复执行。虚拟线程的挂载和卸载频繁且透明，并且不会阻塞任何 OS 线程。
守护线程
Daemon（守护）线程是一种支持型线程，因为它主要被用作程序中后台调度以及支持性工作。这意味着，当一个Java虚拟机中不存在非Daemon线程的时候，Java虚拟机将会退出。可以通过调用Thread.setDaemon(true)将线程设置为Daemon线程。我们一般用不上，比如垃圾回收线程就是Daemon线程。
Daemon线程被用作完成支持性工作，但是在Java虚拟机退出时Daemon线程中的finally块并不一定会执行。在构建Daemon线程时，不能依靠finally块中的内容来确保执行关闭或清理资源的逻辑。
线程间的通信和协调、协作
很多的时候，孤零零的一个线程工作并没有什么太多用处，更多的时候，我们是很多线程一起工作，而且是这些线程间进行通信，或者配合着完成某项工作，这就离不开线程间的通信和协调、协作。
管道的输入和输出流
1、页面点击导出后，后台触发导出任务，然后将mysql 中的数据根据导出条件查询出来，生成 Excel文件，然后将文件上传到 oss，最后发步一个下载文件的链接。
2、和银行以及金融机构对接时，从本地某个数据源查询数据后，上报 xml 格式的数据，给到指定的 ftp、或是 oss 的某个目录下也是类似的。
我们一般的做法是，先将文件写入到本地磁盘，然后从文件磁盘读出来上传到云盘，但是通过Java中的管道输入输出流一步到位，则可以避免写入磁盘这一步。
Java中的管道输入/输出流主要包括了如下4种具体实现：PipedOutputStream、PipedInputStream、PipedReader和PipedWriter，前两种面向字节，而后两种面向字符。
join方法
面试题
现在有T1、T2、T3三个线程，你怎样保证T2在T1执行完后执行，T3在T2执行完后执行？
join()
把指定的线程加入到当前线程，可以将两个交替执行的线程合并为顺序执行。比如在线程B中调用了线程A的Join()方法，直到线程A执行完毕后，才会继续执行线程B剩下的代码。
synchronized内置锁
线程开始运行，拥有自己的栈空间，就如同一个脚本一样，按照既定的代码一步一步地执行，直到终止。但是，每个运行中的线程，如果仅仅是孤立地运行，那么没有一点儿价值，或者说价值很少，如果多个线程能够相互配合完成工作，包括数据之间的共享，协同处理事情。这将会带来巨大的价值。
Java支持多个线程同时访问一个对象或者对象的成员变量，关键字synchronized可以修饰方法或者以同步块的形式来进行使用，它主要确保多个线程在同一个时刻，只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性和排他性，又称为内置锁机制。
对象锁和类锁：
对象锁是用于对象实例方法，或者一个对象实例上的，类锁是用于类的静态方法或者一个类的class对象上的。我们知道，类的对象实例可以有很多个，但是每个类只有一个class对象，所以不同对象实例的对象锁是互不干扰的，但是每个类只有一个类锁。
但是有一点必须注意的是，其实类锁只是一个概念上的东西，并不是真实存在的，类锁其实锁的是每个类的对应的class对象。类锁和对象锁之间也是互不干扰的。
错误的加锁和原因分析
原因：虽然我们对i进行了加锁，但是
但是当我们反编译这个类的class文件后，可以看到i++实际是，
本质上是返回了一个新的Integer对象。也就是每个线程实际加锁的是不同的Integer对象。
volatile，最轻量的通信/同步机制
volatile保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
不加volatile时，子线程无法感知主线程修改了ready的值，从而不会退出循环，而加了volatile后，子线程可以感知主线程修改了ready的值，迅速退出循环。
但是volatile不能保证数据在多个线程下同时写时的线程安全，volatile最适用的场景：一个线程写，多个线程读。
等待/通知机制
线程之间相互配合，完成某项工作，比如：一个线程修改了一个对象的值，而另一个线程感知到了变化，然后进行相应的操作，整个过程开始于一个线程，而最终执行又是另一个线程。前者是生产者，后者就是消费者，这种模式隔离了“做什么”（what）和“怎么做”（How），简单的办法是让消费者线程不断地循环检查变量是否符合预期在while循环中设置不满足的条件，如果条件满足则退出while循环，从而完成消费者的工作。却存在如下问题：
1）难以确保及时性。
2）难以降低开销。如果降低睡眠的时间，比如休眠1毫秒，这样消费者能更加迅速地发现条件变化，但是却可能消耗更多的处理器资源，造成了无端的浪费。
等待/通知机制则可以很好的避免，这种机制是指一个线程A调用了对象O的wait()方法进入等待状态，而另一个线程B调用了对象O的notify()或者notifyAll()方法，线程A收到通知后从对象O的wait()方法返回，进而执行后续操作。上述两个线程通过对象O来完成交互，而对象上的wait()和notify/notifyAll()的关系就如同开关信号一样，用来完成等待方和通知方之间的交互工作。
notify()：
通知一个在对象上等待的线程,使其从wait方法返回,而返回的前提是该线程获取到了对象的锁，没有获得锁的线程重新进入WAITING状态。
notifyAll()：
通知所有等待在该对象上的线程
wait()
调用该方法的线程进入 WAITING状态,只有等待另外线程的通知或被中断才会返回.需要注意,调用wait()方法后,会释放对象的锁
wait(long)
超时等待一段时间,这里的参数时间是毫秒,也就是等待长达n毫秒,如果没有通知就超时返回
wait (long,int)
对于超时时间更细粒度的控制,可以达到纳秒
等待和通知的标准范式
等待方遵循如下原则。
1）获取对象的锁。
2）如果条件不满足，那么调用对象的wait()方法，被通知后仍要检查条件。
3）条件满足则执行对应的逻辑。
通知方遵循如下原则。
1）获得对象的锁。
2）改变条件。
3）通知所有等待在对象上的线程。
在调用wait（）、notify()系列方法之前，线程必须要获得该对象的对象级别锁，即只能在同步方法或同步块中调用wait（）方法、notify()系列方法，进入wait（）方法后，当前线程释放锁，在从wait（）返回前，线程与其他线程竞争重新获得锁， 执行notify()系列方法的线程退出调用了notifyAll的synchronized代码块的时候后，他们就会去竞争。如果其中一个线程获得了该对象锁，它就会继续往下执行，在它退出synchronized代码块，释放锁后，其他的已经被唤醒的线程将会继续竞争获取该锁，一直进行下去，直到所有被唤醒的线程都执行完毕。
notify和notifyAll应该用谁
尽可能用notifyall()，谨慎使用notify()，因为notify()只会唤醒一个线程，我们无法确保被唤醒的这个线程一定就是我们需要唤醒的线程
等待超时模式实现一个连接池
调用场景：调用一个方法时等待一段时间（一般来说是给定一个时间段），如果该方法能够在给定的时间段之内得到结果，那么将结果立刻返回，反之，超时返回默认结果。
假设等待时间段是T，那么可以推断出在当前时间now+T之后就会超时
等待持续时间：REMAINING=T。
•超时时间：FUTURE=now+T。
// 对当前对象加锁
public synchronized Object get(long mills) throws InterruptedException {
long future = System.currentTimeMillis() + mills;
long remaining = mills;
// 当超时大于0并且result返回值不满足要求
while ((result == null) && remaining > 0) {
wait(remaining);
remaining = future - System.currentTimeMillis();
}
return result;
}
具体实现参见：包cn.tulingxueyuan.base.pool下的代码
客户端获取连接的过程被设定为等待超时的模式，也就是在1000毫秒内如果无法获取到可用连接，将会返回给客户端一个null。设定连接池的大小为10个，然后通过调节客户端的线程数来模拟无法获取连接的场景。
它通过构造函数初始化连接的最大上限，通过一个双向队列来维护连接，调用方需要先调用fetchConnection(long)方法来指定在多少毫秒内超时获取连接，当连接使用完成后，需要调用releaseConnection(Connection)方法将连接放回线程池
面试题
方法和锁
调用yield() 、sleep()、wait()、notify()等方法对锁有何影响？
yield() 、sleep()被调用后，都不会释放当前线程所持有的锁。
调用wait()方法后，会释放当前线程持有的锁，而且当前被唤醒后，会重新去竞争锁，锁竞争到后才会执行wait方法后面的代码。
调用notify()系列方法后，对锁无影响，线程只有在syn同步代码执行完后才会自然而然的释放锁，所以notify()系列方法一般都是syn同步代码的最后一行。
wait和notify
为什么wait和notify方法要在同步块中调用？
主要是因为Java API强制要求这样做，如果你不这么做，你的代码会抛出IllegalMonitorStateException异常。其实真实原因是：
这个问题并不是说只在Java语言中会出现，而是会在所有的多线程环境下出现。
假如我们有两个线程，一个消费者线程，一个生产者线程。生产者线程的任务可以简化成将count加一，而后唤醒消费者；消费者则是将count减一，而后在减到0的时候陷入睡眠：
生产者伪代码：
count+1;
notify();
消费者伪代码：
while(count<=0)
wait()
count--
这里面有问题。什么问题呢？
生产者是两个步骤：
- count+1;
- notify();
消费者也是两个步骤：
- 检查count值；
- 睡眠或者减一；
万一这些步骤混杂在一起呢？比如说，初始的时候count等于0，这个时候消费者检查count的值，发现count小于等于0的条件成立；就在这个时候，发生了上下文切换，生产者进来了，噼噼啪啪一顿操作，把两个步骤都执行完了，也就是发出了通知，准备唤醒一个线程。这个时候消费者刚决定睡觉，还没睡呢，所以这个通知就会被丢掉。紧接着，消费者就睡过去了……
这就是所谓的lost wake up问题。
那么怎么解决这个问题呢？
现在我们应该就能够看到，问题的根源在于，消费者在检查count到调用wait()之间，count就可能被改掉了。
这就是一种很常见的竞态条件。
很自然的想法是，让消费者和生产者竞争一把锁，竞争到了的，才能够修改count的值。
为什么你应该在循环中检查等待条件?
处于等待状态的线程可能会收到错误警报和伪唤醒，如果不在循环中检查等待条件，程序就会在没有满足结束条件的情况下退出。因此，当一个等待线程醒来时，不能认为它原来的等待状态仍然是有效的，在notify()方法调用之后和等待线程醒来之前这段时间它可能会改变。这就是在循环中使用wait()方法效果更好的原因。
CompleteableFuture
JDK1.8才新加入的一个实现类CompletableFuture，实现了Future， CompletionStage两个接口。实现了Future接口，意味着可以像以前一样通过阻塞或者轮询的方式获得结果。
创建
除了直接new出一个CompletableFuture的实例，还可以通过工厂方法创建CompletableFuture的实例
工厂方法：
Asynsc表示异步,而supplyAsync与runAsync不同在与前者异步返回一个结果,后者是void.第二个函数第二个参数表示是用我们自己创建的线程池,否则采用默认的ForkJoinPool.commonPool()作为它的线程池。
获得结果的方法
public T get()
public T get(long timeout, TimeUnit unit)
public T getNow(T valueIfAbsent)
public T join()
getNow有点特殊，如果结果已经计算完则返回结果或者抛出异常，否则返回给定的valueIfAbsent值。
join返回计算的结果或者抛出一个unchecked异常(CompletionException)，它和get对抛出的异常的处理有些细微的区别。
辅助方法
public static CompletableFuture allOf(CompletableFuture... cfs)
public static CompletableFuture