首页  思维导图  详情

Java

2023-11-22 09:01:01   0  举报





AI智能生成

为你推荐

查看更多



Java

Java技术架构

JAVA

java

java

java笔记

java

jvm

作者其他创作

大纲/内容

存储虚拟机加载的类信息、常量、静态变量等

方法区

存放对象实例，所有对象、数组实例都在堆中分配

jvm管理内存最大的一块区域

堆

共享域

栈也称线程栈，每个线程在栈中都是独立开辟一块空间，互不干扰

栈中一般包含：本地变量、操作数栈、动态链接、方法出口

栈

由native关键字修饰的方法开辟的一块空间

本地栈

记录程序下一行执行代码的指令行

程序计数器

私有域

数据结构

young gc/minor gc

老年代gc，只有CMS有单独的老年代回收

old gc/major gc

子主题

full gc

Mixed GC是G1中特有的概念，主要就是说在G1中，一旦老年代占据堆内存的45%了，就要触发Mixed GC，此时对年轻代、以及部分老年代进行回收。对应的参数设置：“-XX:InitiatingHeapOccupancyPercent”，他的默认值是45%，可以进行按需要修改。

Mixed GC

什么时候会触发GC？

新对象优先分配eden区域

JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。比如设置 JVM 参数：-XX:PretenureSizeThreshold=1000000 - XX:+UseSerialGC

大对象直接进入老年代

对象年龄超过默认阀值，将进入老年代 -XX:MaxTenuringThreshold 可以设置进入老年代默认年龄阀值

长期存活的对象进入老年代

一批对象（年龄1+年龄2+年龄6）在survior区域超过总大小的50%，年龄代大的一批对象将进入老年代

让可能长期存活的对象尽早的进入老年代

这样做的目的？

这种机制一般在minor gc之后触发

动态年龄判断

Minor GC后在survor区域放不下的对象，部分移入老年代

每次进行minor gc 前，先判断老年代剩余可用空间大小是否小于年轻代所有对象（包括垃圾对象）之和，如果否则进行minor gc，如果是，则看是否有配置“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)参数，如果没有配置则进行full gc回收垃圾对象，如果有配置，则判断老年代剩余可用空间大小是否小于之前每次进行minor gcfont color=\"#d32f2f\

老年代空间分配担保机制

内存分配与回收

以gc roots为根节点，一直往下搜索，找到的对象都标记为非垃圾对象，其余为标记的对象都为垃圾对象

本地变量、静态变量、本地方法栈变量等

什么可以作为gc roots

可达性算法

如果对象被引用，则计数器+1，如果引用释放，则计数器-1，如果计数器为0，则对象没有被引用，即为垃圾对象

引用计数

普通的变量引用

强引用

将对象用WeakReference软引用类型的对象包裹，软引用跟没引用差不多，gc会直接回收掉，基本不用

弱引用

将对象用SoftReference弱引用类型的对象包裹，正常情况下不会被回收，只有当gc回收后还是没有空间存放新对象，这时才会回收弱引用类型包裹的对象

可以用来实现内存敏感的高速缓存

软引用

也称为幽灵引用或者幻影引用，它是最弱的一种引用，几乎不用

虚引用

常见引用类型

标记的前提是在进行可达性分析后发现没有与gc roots相连接的引用链

finalize()方法最终判断对象是否存活

如何判断对象可以被回收

分为标记和清除两个阶段，先标记出所有要回收的对象，标记完成后统一回收所有要回收的对象

它是最基础的收集算法，效率也很高

有一个明显的问题，就是空间问题，标记清除后会产生大量不连续的碎片

标记清除算法

根据老年代的特点出的一套标记算法

标记过程与“标记-清除”算法一样，但后续步骤不是对可回收对象进行回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存

标记整理算法

为解决效率问题诞生

它可以将内存分为两个大小相同的区域，每次使用其中的一块区域。当其中一块区域使用完之后，就将还存活的对象复制到另一块区域，然后再把使用的空间一次清理掉，这样使每次内存回收都是对内存区间的一半进行回收

复制算法

是指不同年代采用不同的收集算法，例如，年轻代和老年代就采用了不同的收集算法，年轻代中基本百分之九十以上的对象是要被回收的，所以采用复制算法收集更高效；老年代中基本都是长期存活的对象，所以基本上都是不需要被回收的，采用标记清除或标记整理的收集算法更为合适

分代算法

垃圾收集算法

单线程的垃圾收集器

没有线程交互的开销，自然单线程收集效率比较高

简单、高效

cms收集器的后备方案

stop the world，必须暂停其他所有用户工作线程

最基本、最悠久的收集器

serial收集器

多线程并发的垃圾收集器

其他（控制参数、回收策略等）与serial收集器相同

真正的能与cms垃圾收集器相配合使用

默认收集线程数与cpu核数相同

parNew收集器

吞吐量就是CPU用于运行用户代码的时间与CPU总耗时的比值

关注点是吞吐量（高效率的利用cpu)

提供了很多参数供用户找到最合适的停顿时间或最大吞吐量

parallel scavenge收集器

关注点是用户停顿时间，是一种以获得最短用户停顿时间为目标的收集器

非常符合在注重用户体验的应用上使用

是HotSpot虚拟机上真正意义上的一款并发收集器

第一次实现了让垃圾收集线程与用户线程基本上同时工作

是一种“标记-清除”算法的实现

第一步，初始标记

第二步，并发标记

第三步，重新标记

第四步，并发清除

整个步骤分为四步

cms收集器

面向服务器的垃圾收集器，主要针对配备多颗处理器或大内存的机器，以极高概率满足gc停顿时间的需求，同时还具备高吞吐量的性能特征

YoungGC并不是说现有的Eden区放满了就会马上触发，而且G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC

Young GC

不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercen)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC

Mined GC

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的

Full GC

G1垃圾收集分类

G1将Java堆区划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region一般情况下Region的大小等于堆大小除以2048，当然也可以通过设置\"-XX:G1HeapRegionSize\"参数指定region大小，但推荐默认

G1收集器优化建议

g1收集器

垃圾收集器

该实例已经被回收

加载该实例的ClassLoader已经被回收

该类的Class对象在任何地方没有被引用，无法在任何地方通过反射访问该类的方法

如何判断一个类是无用类

优先调整堆的大小，让服务器自己来选择

如果内存小于100M，则优先使用串行收集器

如果是单核，且没有停顿时间要求，串行或JVM自己选择

如果停顿时间允许超过1秒，则用并行或JVM自己选择

如果响应时间最重要，并且不能超过1秒，使用并发收集器下图有连线的可以搭配使用，官方推荐使用G1，因为性能高

如何选择垃圾收集器

亿级流量电商系统如何优化JVM参数设置(ParNew+CMS)

每秒几十万并发的系统如何优化JVM

调优案例

用jps查看进程ID

前置

此命令可以用来查看内存信息，实例个数以及占用内存大小

jmap ‐histo 14660 #查看历史生成的实例

jmap ‐histo:live 14660 #查看当前存活的实例，执行过程中可能会触发一次full gc

jmap -heap 14660 #查看堆信息

jmap

用jstack加进程id查找死锁，找出占用cpu最高的线程堆栈信息

jstack 14660 #用jstack加进程id查找线程信息

jstack

调优工具

其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。尽量别让对象进入老年代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响。

优化思路

用 jstat gc -pid 命令可以计算出如下一些关键数据，有了这些数据就可以采用之前介绍过的优化思路，先给自己的系统设置一些初始性的 JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。

初始设置JVM参数

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率。

年轻代对象增长的速率

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC 公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

Young GC的触发频率和每次耗时

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden， survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次 Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

每次Young GC后有多少对象存活和进入老年代

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。

Full GC的触发频率和每次耗时

优化步骤

JVM运行情况预估

JVM

模拟优化器执行sql语句，发现查询语句的性能瓶颈

会在 explain 的基础上额外提供一些查询优化的信息。紧随其后通过 show warnings 命令可以得到优化后的查询语句，从而看出优化器优化了什么。额外还有 filtered 列，是一个半分比的值，rows * filtered/100 可以估算出将要和 explain 中前一个表进行连接的行数（前一个表指 explain 中的id值比当前表id值小的表）。

explain extended

相比 explain 多了个 partitions 字段，如果查询是基于分区表的话，会显示查询将访问的分区。

explain partitions

两个变种

id列的编号是 select 的序列号，有几个 select 就有几个id，并且id的顺序是按 select 出现的顺序增长的。 id列越大执行优先级越高，id相同则从上往下执行，id为NULL最后执行。

表示对应行是简单还是复杂的查询。

simple：简单查询。查询不包含子查询和union

primary：复杂查询中最外层的 select

subquery：包含在 select 中的子查询（不在 from 子句中）

derived：包含在 from 子句中的子查询。MySQL会将结果存放在一个临时表中，也称为派生表（derived的英文含义）

union：在 union 中的第二个和随后的 select

值列表

select_type

table

partitions

这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行记录的大概范围。依次从最优到最差分别为：system > const > eq_ref > ref > range > index > ALL 一般来说，得保证查询达到range级别，最好达到ref

NULL：mysql能够在优化阶段分解查询语句，在执行阶段用不着再访问表或索引。例如：在索引列中选取最小值，可以单独查找索引来完成，不需要在执行时访问表

eq_ref：primary key 或 unique key 索引的所有部分被连接使用，最多只会返回一条符合条件的记录。这可能是在 const 之外最好的联接类型了，简单的 select 查询不会出现这种 type。

ref：相比 eq_ref，不使用唯一索引，而是使用普通索引或者唯一性索引的部分前缀，索引要和某个值相比较，可能会找到多个符合条件的行。

index：扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这种通常比ALL快一些。

ALL：即全表扫描，扫描你的聚簇索引的所有叶子节点。通常情况下这需要增加索引来进行优化了。

type

这一列显示查询可能使用哪些索引来查找。 explain 时可能出现 possible_keys 有列，而 key 显示 NULL 的情况，这种情况是因为表中数据不多，mysql认为索引对此查询帮助不大，选择了全表查询。如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查 where 子句看是否可以创造一个适当的索引来提高查询性能，然后用 explain 查看效果。

possible_keys

这一列显示mysql实际采用哪个索引来优化对该表的访问。如果没有使用索引，则该列是 NULL。如果想强制mysql使用或忽视possible_keys列中的索引，在查询中使用 force index、ignore index。

key

这一列显示了mysql在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列。举例来说，film_actor的联合索引 idx_film_actor_id 由 film_id 和 actor_id 两个int列组成，并且每个int是4字节。通过结果中的key_len=4可推断出查询使用了第一个列：film_id列来执行索引查找。

字符串，char(n)和varchar(n)，5.0.3以后版本中，n均代表字符数，而不是字节数，如果是utf-8，一个数字或字母占1个字节，一个汉字占3个字节 char(n)：如果存汉字长度就是 3n 字节 varchar(n)：如果存汉字则长度是 3n + 2 字节，加的2字节用来存储字符串长度，因为 varchar是变长字符串数值类型tinyint：1字节 smallint：2字节 int：4字节 bigint：8字节时间类型date：3字节timestamp：4字节 datetime：8字节如果字段允许为 NULL，需要1字节记录是否为 NULL

key_len计算规则如下：

key_len

这一列显示了在key列记录的索引中，表查找值所用到的列或常量，常见的有：const（常量），字段名（例：film.id）

ref

这一列是mysql估计要读取并检测的行数，注意这个不是结果集里的行数。

rows

filtered

这一列展示的是额外信息。

覆盖索引定义：mysql执行计划explain结果里的key有使用索引，如果select后面查询的字段都可以从这个索引的树中获取，这种情况一般可以说是用到了覆盖索引，extra里一般都有using index；覆盖索引一般针对的是辅助索引，整个查询结果只通过辅助索引就能拿到结果，不需要通过辅助索引树找到主键，再通过主键去主键索引树里获取其它字段值

Using index：使用覆盖索引

Using where：使用 where 语句来处理结果，并且查询的列未被索引覆盖

Using index condition：查询的列不完全被索引覆盖，where条件中是一个前导列的范围；

mysql> explain select distinct name from actor;actor.name没有索引，此时创建了张临时表来distinct

Using temporary：mysql需要创建一张临时表来处理查询。出现这种情况一般是要进行优化的，首先是想到用索引来优化。

mysql> explain select * from actor order by name;actor.name未创建索引，会浏览actor整个表，保存排序关键字name和对应的id，然后排序name并检索行记录

Using filesort：将用外部排序而不是索引排序，数据较小时从内存排序，否则需要在磁盘完成排序。这种情况下一般也是要考虑使用索引来优化的。

Select tables optimized away：使用某些聚合函数（比如 max、min）来访问存在索引的某个字段是

常见的重要值如下：

extra

列

Explain工具介绍

全值匹配

最左前缀法则

不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描

存储引擎不能使用索引中范围条件右边的列

尽量使用覆盖索引（只访问索引的查询（索引列包含查询列）），减少 select * 语句

mysql在使用不等于（！=或者<>），not in ，not exists 的时候无法使用索引会导致全表扫描 < 小于、 > 大于、 <=、>= 这些，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引

like以通配符开头（'$abc...'）mysql索引失效会变成全表扫描操作

字符串不加单引号索引失效

少用or或in，用它查询时，mysql不一定使用索引，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引，详见范围查询优化

索引最佳实践

索引使用总结：

Mysql调优

程序由指令和数据组成，但这些指令要运行，数据要读写，就必须将指令加载至 CPU，数据加载至内存。在指令运行过程中还需要用到磁盘、网络等设备。进程就是用来加载指令、管理内存、管理 IO 的。

当一个程序被运行，从磁盘加载这个程序的代码至内存，这时就开启了一个进程。

进程就可以视为程序的一个实例。大部分程序可以同时运行多个实例进程（例如记事本、画图、浏览器等），也有的程序只能启动一个实例进程（例如网易云音乐、360 安全卫士等）。

操作系统会以进程为单位，分配系统资源（CPU时间片、内存等资源），进程是资源分配的最小单位。

进程

线程是调度CPU资源的最小单位

Java线程与OS线程保持1:1的映射关系，也就是说有一个java线程也会在操作系统里有一个对应的线程

新建

NEW

运行

RUNNABLE

阻塞

BLOCKED

等待

WAITING

超时等待

TIMED_WAITING

终结

TERMINATED

Java线程有多种生命状态

状态切换如下图

指线程之间所具有的一种制约关系，一个线程的执行依赖另一个线程的消息，当它没有得到另一个线程的消息时应等待，直到消息到达时才被唤醒

线程同步

指对于共享的进程系统资源，在各单个线程访问时的排它性。当有若干个线程都要使用某一共享资源时，任何时刻最多只允许一个线程去使用，其它要使用该资源的线程必须等待，直到占用资源者释放该资源。线程互斥可以看成是一种特殊的线程同步。

线程互斥

临界区:通过对多线程的串行化来访问公共资源或一段代码，速度快，适合控制数据访问。（在一段时间内只允许一个线程访问的资源就称为临界资源）。互斥量:为协调共同对一个共享资源的单独访问而设计的。信号量:为控制一个具有有限数量用户资源而设计。事件:用来通知线程有一些事件已发生，从而启动后继任务的开始。

线程同步互斥的控制方法

线程的同步、互斥

指CPU(中央处理单元)从一个进程或线程到另一个进程或线程的切换

上下文切换只能在内核模式下发生。

上下文切换是多任务操作系统的一个基本特性

就CPU时间而言，上下文切换对系统来说是一个巨大的成本，实际上，它可能是操作系统上成本最高的操作

与其他操作系统(包括一些其他类unix系统)相比，Linux的众多优势之一是它的上下文切换和模式切换成本极低

概念

暂停一个进程的处理，并将该进程的CPU状态(即上下文)存储在内存中的某个地方从内存中获取下一个进程的上下文，并在CPU的寄存器中恢复它返回到程序计数器指示的位置(即返回到进程被中断的代码行)以恢复进程

上下文切换步骤

上下文切换（Context switch）

调用 sleep 会让当前线程从 Running 进入TIMED_WAITING状态，不会释放对象锁

其它线程可以使用 interrupt 方法打断正在睡眠的线程，这时 sleep 方法会抛出 InterruptedException，并且会清除中断标志

睡眠结束后的线程未必会立刻得到执行

sleep当传入参数为0时，和yield相同

sleep方法

yield会释放CPU资源，让当前线程从 Running 进入 Runnable状态，让优先级更高（至少是相同）的线程获得执行机会，不会释放对象锁；

假设当前进程只有main线程，当调用yield之后，main线程会继续运行，因为没有比它优先级更高的线程；

具体的实现依赖于操作系统的任务调度器

yield方法

等待调用join方法的线程结束之后，程序再继续执行，一般用于等待异步线程执行完结果之后才能继续运行的场景。

join方法

stop()方法已经被jdk废弃，原因就是stop()方法太过于暴力，强行把执行到一半的线程终止。

stop会释放对象锁，可能会造成数据不一致

stop方法

Thread常用的方法

Java没有提供一种安全、直接的方法来停止某个线程，而是提供了中断机制。中断机制是一种协作机制，也就是说通过中断并不能直接终止另一个线程，而需要被中断的线程自己处理。被中断的线程拥有完全的自主权，它既可以选择立即停止，也可以选择一段时间后停止，也可以选择压根不停止

描述

将线程的中断标志位设置为true，不会停止线程

interrupt()

判断当前线程的中断标志位是否为true，不会清除中断标志位

isInterrupted()

判断当前线程的中断标志位是否为true，并清除中断标志位，重置为fasle

Thread.interrupted()

API的使用

如何利用中断机制优雅的停止线程？

sleep可以被中断抛出中断异常：sleep interrupted，清除中断标志位

wait可以被中断抛出中断异常：InterruptedException，清除中断标志位

sleep 期间能否感受到中断？

问题

Java线程的中断机制

volatile有两大特性，一是可见性，二是有序性，禁止指令重排序，其中可见性就是可以让线程之间进行通信。

volatile

可以基于wait和notify方法来实现，在一个线程内调用该线程锁对象的wait方法，线程将进入等待队列进行等待直到被唤醒。

等待唤醒(等待通知)机制

是JDK中用来实现线程阻塞和唤醒的工具，线程调用park则等待“许可”，调用unpark则为指定线程提供“许可”。使用它可以在任何场合使线程阻塞，可以指定任何线程进行唤醒，并且不用担心阻塞和唤醒操作的顺序，但要注意连续多次唤醒的效果和一次唤醒是一样的。

LockSupport

管道输入/输出流和普通的文件输入/输出流或者网络输入/输出流不同之处在于，它主要用于线程之间的数据传输，而传输的媒介为内存。管道输入/输出流主要包括了如下4种具体实现：PipedOutputStream、PipedInputStream、PipedReader和PipedWriter，前两种面向字节，而后两种面向字符。

管道输入输出流

join可以理解成是线程合并，当在一个线程调用另一个线程的join方法时，当前线程阻塞等待被调用join方法的线程执行完毕才能继续执行，所以join的好处能够保证线程的执行顺序，但是如果调用线程的join方法其实已经失去了并行的意义，虽然存在多个线程，但是本质上还是串行的，最后join的实现其实是基于等待通知机制的。

Thread.join

Java线程间通信

1.CAS涉及到用户模式到内核模式的切换吗？

2.为什么说创建Java线程的方式本质上只有一种？Java线程和go语言的协程有什么区别？

3.如何优雅的终止线程？

4.Java线程之间如何通信的，有哪些方式？

线程

一种基于线程之上，但又比线程更加轻量级的存在，协程不是被操作系统内核所管理，而完全是由程序所控制（也就是在用户态执行），具有对内核来说不可见的特性

这样带来的好处就是性能得到了很大的提升，不会像线程切换那样消耗资源

图

协程

进程基本上相互独立的，而线程存在于进程内，是进程的一个子集

进程拥有共享的资源，如内存空间等，供其内部的线程共享

进程间通信较为复杂同一台计算机的进程通信称为 IPC（Inter-process communication）不同计算机之间的进程通信，需要通过网络，并遵守共同的协议，例如 HTTP

线程通信相对简单，因为它们共享进程内的内存，一个例子是多个线程可以访问同一个共享变量

线程更轻量，线程上下文切换成本一般上要比进程上下文切换低

线程与进程的区别

管道可用于具有亲缘关系的父子进程间的通信，有名管道除了具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。

管道（pipe）及有名管道（named pipe）

信号是在软件层次上对中断机制的一种模拟，它是比较复杂的通信方式，用于通知进程有某事件发生，一个进程收到一个信号与处理器收到一个中断请求效果上可以说是一致的。

信号（signal）

消息队列是消息的链接表，它克服了上两种通信方式中信号量有限的缺点，具有写权限得进程可以按照一定得规则向消息队列中添加新信息；对消息队列有读权限得进程则可以从消息队列中读取信息。

消息队列（message queue）

可以说这是最有用的进程间通信方式。它使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据得更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。

共享内存（shared memory）

主要作为进程之间及同一种进程的不同线程之间得同步和互斥手段。

信号量（semaphore）

这是一种更为一般得进程间通信机制，它可用于网络中不同机器之间的进程间通信，应用非常广泛。

套接字（socket）

进程间通信的方式

线程执行时间由线程本身来控制，线程把自己的工作执行完之后，要主动通知系统切换到另外一个线程上。最大好处是实现简单，且切换操作对线程自己是可知的，没啥线程同步问题。坏处是线程执行时间不可控制，如果一个线程有问题，可能一直阻塞在那里

协同式线程调度

每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定（Java中，Thread.yield()可以让出执行时间，但无法获取执行时间）。线程执行时间系统可控，也不会有一个线程导致整个进程阻塞

抢占式线程调度

线程调度方式

希望系统能给某些线程多分配一些时间，给一些线程少分配一些时间，可以通过设置线程优先级来完成。Java语言一共10个级别的线程优先级（Thread.MIN_PRIORITY至Thread.MAX_PRIORITY）

但优先级并不是很靠谱，因为Java线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统。

Java线程调度就是抢占式调度

Java线程的调度机制

线程基础

是一个线程缓存

线程是稀缺资源，如果被无限创建，不仅消耗系统资源，还会降低系统的稳定性

是对线程进行统一分配、调优和监控

线程池概念

单个任务处理时间比较短，需要处理的任务数量大的情况

什么时候需要用线程池？

重用存在的线程，减少线程创建、消亡消耗的时间，提高性能

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

线程池的优势

Runnable、Callable、Thread

实现线程的方式

Running

Shutdown

Stop

Tidying

Terminate

线程池的五种状态

线程池

Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在

它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式

JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝，前面说过，工作内存是每个线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成。

什么是JMM模型？

JMM与JVM内存区域的划分是不同的概念层次

更恰当说JMM描述的是一组规则，通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式

JMM是围绕原子性，有序性、可见性展开

JMM与Java内存区域唯一相似点，都存在共享数据区域和私有数据区域，在JMM中主内存属于共享数据区域，从某个程度上讲应该包括了堆和方法区，而工作内存数据线程私有数据区域，从某个程度上讲则应该包括程序计数器、虚拟机栈以及本地方法栈。

主要存储的是Java实例对象

所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量还是方法中的本地变量(也称局部变量)

当然也包括了共享的类信息、常量、静态变量。

由于是共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题。

主内存

主要存储当前方法的所有本地变量信息(工作内存中存储着主内存中的变量副本拷贝)

每个线程只能访问自己的工作内存，即线程中的本地变量对其它线程是不可见的，就算是两个线程执行的是同一段代码，它们也会各自在自己的工作内存中创建属于当前线程的本地变量，当然也包括了字节码行号指示器、相关Native方法的信息。

注意由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题。

模型如下图所示

工作内存

线程，工作内存，主内存工作交互图（基于JMM规范）：

JMM不同于JVM内存区域模型

通过对前面的硬件内存架构、Java内存模型以及Java多线程的实现原理的了解，我们应该已经意识到，多线程的执行最终都会映射到硬件处理器上进行执行，但Java内存模型和硬件内存架构并不完全一致。对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没有工作内存(线程私有数据区域)和主内存(堆内存)之分，也就是说Java内存模型对内存的划分对硬件内存并没有任何影响，因为JMM只是一种抽象的概念，是一组规则，并不实际存在，不管是工作内存的数据还是主内存的数据，对于计算机硬件来说都会存储在计算机主内存中，当然也有可能存储到CPU缓存或者寄存器中，因此总体上来说，Java内存模型和计算机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉。(注意对于Java内存区域划分也是同样的道理)

Java内存模型与硬件内存架构的关系

在明白了Java内存区域划分、硬件内存架构、Java多线程的实现原理与Java内存模型的具体关系后，接着来谈谈Java内存模型存在的必要性。由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据，线程与主内存中的变量操作必须通过工作内存间接完成，主要过程是将变量从主内存拷贝的每个线程各自的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，如果存在两个线程同时对一个主内存中的实例对象的变量进行操作就有可能诱发线程安全问题。假设主内存中存在一个共享变量x，现在有A和B两条线程分别对该变量x=1进行操作，A/B线程各自的工作内存中存在共享变量副本x。假设现在A线程想要修改x的值为2，而B线程却想要读取x的值，那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢？答案是，不确定，即B线程有可能读取到A线程更新前的值1，也有可能读取到A线程更新后的值2，这是因为工作内存是每个线程私有的数据区域，而线程A变量x时，首先是将变量从主内存拷贝到A线程的工作内存中，然后对变量进行操作，操作完成后再将变量x写回主内，而对于B线程的也是类似的，这样就有可能造成主内存与工作内存间数据存在一致性问题，假如A线程修改完后正在将数据写回主内存，而B线程此时正在读取主内存，即将x=1拷贝到自己的工作内存中，这样B线程读取到的值就是x=1，但如果A线程已将x=2写回主内存后，B线程才开始读取的话，那么此时B线程读取到的就是x=2，但到底是哪种情况先发生呢？

以上关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成。

JMM存在的必要性

如果要把一个变量从主内存中复制到工作内存中，就需要按顺序地执行read和load操作，如果把变量从工作内存中同步到主内存中，就需要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。

（1）lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态（2）unlock(解锁)：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定（3）read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用（4）load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中（5）use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎（6）assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量（7）store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作（8）write(写入)：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中

1）不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中2）一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或者assign）的变量。即就是对一个变量实施use和store操作之前，必须先自行assign和load操作。3）一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现。4）如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量之前需要重新执行load或assign操作初始化变量的值。5）如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。6）对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）

同步规则分析

数据同步八大原子操作

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响

原子性

指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值

在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题

另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程序轮序执行的问题，从而也就导致可见性问题。

可见性

指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象

有序性

并发编程的可见性，原子性与有序性问题

除JVM自身提供的对基本数据类型读写操作的原子性

还可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块

原子性问题

volatile关键字保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值

可见性问题

在Java里面，可以通过volatile关键字来保证一定的“有序性”

另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性

有序性问题

JMM如何解决原子性&可见性&有序性问题

不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序

as-if-serial语义

程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行。锁规则解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。volatile规则 volatile变量的写，先发生于读，这保证了volatile变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的线程总是能够看到该变量的最新值。线程启动规则线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量的修改对线程B可见传递性 A先于B ，B先于C 那么A必然先于C线程终止规则线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法成功返回后，线程B对共享变量的修改将对线程A可见。线程中断规则对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。对象终结规则对象的构造函数执行，结束先于finalize()方法

happens-before 原则

volatile是Java虚拟机提供的轻量级的同步机制

保证被volatile修饰的共享变量对所有线程总数可见的，也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。

禁止指令重排序优化

作用

关于volatile的可见性作用，我们必须意识到被volatile修饰的变量对所有线程总数立即可见的，对volatile变量的所有写操作总是能立刻反应到其他线程中

volatile的可见性

注意：volatile能保证可见性，但无法保证原子性，依然存在线程安全问题

volatile内存语义

JMM

实际上，所有的并发模式在解决线程安全问题时，采用的方案都是序列化访问临界资源。即在同一时刻，只能有一个线程访问临界资源，也称作同步互斥访问。Java 中，提供了两种方式来实现同步互斥访问：synchronized 和 Lock同步器的本质就是加锁加锁目的：序列化访问临界资源，即同一时刻只能有一个线程访问临界资源(同步互斥访问)不过有一点需要区别的是：当多个线程执行一个方法时，该方法内部的局部变量并不是临界资源，因为这些局部变量是在每个线程的私有栈中，因此不具有共享性，不会导致线程安全问题。

如何解决线程并发安全问题？

系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading很高

CPU bound的程序一般而言CPU占用率相当高

这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间

线程数一般设置为：线程数 = CPU核数+1 (现代CPU支持超线程)

CPU密集型（CPU-bound）

IO密集型指的是系统的CPU性能相对硬盘、内存要好很多，此时，系统运作，大部分的状况是CPU在等I/O (硬盘/内存) 的读/写操作，此时CPU Loading并不高。

I/O bound的程序一般在达到性能极限时，CPU占用率仍然较低

这可能是因为任务本身需要大量I/O操作，而pipeline做得不是很好，没有充分利用处理器能力。

线程数一般设置为：线程数 = （（线程等待时间+线程CPU时间）/线程CPU时间）* CPU数目

IO密集型（I/O bound）

我们可以把任务分为计算密集型和IO密集型。计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少，因此，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，完全无法提升运行效率。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。

CPU密集型 vs IO密集型

任务性质类型

目标都是最大化CPU的使用率

指在同一时刻，多条指令在多个处理器上同时执行。无论从宏观还是微观的角度，都是同时执行的

当一个线程修改了共享变量的值，其他线程能够看到修改的值

Java 内存模型依赖主内存作为传递媒介的方法来实现可见性

通过 volatile 关键字保证可见性。通过内存屏障保证可见性。通过 synchronized 关键字保证可见性。通过 Lock保证可见性。通过 final 关键字保证可见性

如何保证可见性

一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。

在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。

不采取任何的原子性保障措施的自增操作并不是原子性的。

通过 synchronized 关键字保证原子性。通过 Lock保证原子性。通过 CAS保证原子性。

如何保证原子性

即程序执行的顺序按照代码的先后顺序执行。

JVM 存在指令重排，所以存在有序性问题。

通过 volatile 关键字保证可见性。通过内存屏障保证可见性。通过 synchronized关键字保证有序性。通过 Lock保证有序性。

如何保证有序性

三大特性

并行

指在同一时刻，只有一条指令在执行，但多个进程指令被快速轮换执行。使得宏观上有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行

并发

并发和并行

对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。

可见性：

对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性（基于这点，我们通过会认为volatile不具备原子性）。volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。

原子性：

对volatile修饰的变量的读写操作前后加上各种特定的内存屏障来禁止指令重排序来保障有序性。

有序性：

volatile的特性

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

volatile写-读的内存语义

volatile的内存语义

多线程模型

CountDownLatch这个类能够使一个线程等待其他线程完成各自的工作后再执行。例如，应用程序的主线程希望在负责启动框架服务的线程已经启动所有的框架服务之后再执行。

CountDownLatch是什么？

使用场景：

CountDownLatch是通过一个计数器来实现的，计数器的初始值为线程的数量。每当一个线程完成了自己的任务后，计数器的值就会减1。当计数器值到达0时，它表示所有的线程已经完成了任务，然后在闭锁上等待的线程就可以恢复执行任务。

CountDownLatch如何工作？

CountDownLatch.countDown()CountDownLatch.await();

API

比如陪媳妇去看病。医院里边排队的人很多，如果一个人的话，要先看大夫，看完大夫再去排队交钱取药。现在我们是双核，可以同时做这两个事（多线程）。假设看大夫花3秒钟，排队交费取药花5秒钟。我们同时搞的话，5秒钟我们就能完成，然后一起回家（回到主线程）。

场景

/** * 看大夫任务 */public class SeeDoctorTask implements Runnable { private CountDownLatch countDownLatch; public SeeDoctorTask(CountDownLatch countDownLatch){ this.countDownLatch = countDownLatch; } public void run() { try { System.out.println(\"开始看医生\"); Thread.sleep(3000); System.out.println(\"看医生结束，准备离开病房\"); } catch (InterruptedException e) { e.printStackTrace(); }finally { if (countDownLatch != null) countDownLatch.countDown(); } }}/** * 排队的任务 */public class QueueTask implements Runnable { private CountDownLatch countDownLatch; public QueueTask(CountDownLatch countDownLatch){ this.countDownLatch = countDownLatch; } public void run() { try { System.out.println(\"开始在医院药房排队买药....\"); Thread.sleep(5000); System.out.println(\"排队成功，可以开始缴费买药\"); } catch (InterruptedException e) { e.printStackTrace(); }finally { if (countDownLatch != null) countDownLatch.countDown(); } }}/** * 配媳妇去看病，轮到媳妇看大夫时 * 我就开始去排队准备交钱了。 */public class CountDownLaunchRunner { public static void main(String[] args) throws InterruptedException { long now = System.currentTimeMillis(); CountDownLatch countDownLatch = new CountDownLatch(2); new Thread(new SeeDoctorTask(countDownLatch)).start(); new Thread(new QueueTask(countDownLatch)).start(); //等待线程池中的2个任务执行完毕，否则一直 countDownLatch.await(); System.out.println(\"over，回家 cost:\"+(System.currentTimeMillis()-now)); }}

示例代码

CountDownLatch应用场景例子

CountDownLatch

Semaphore 字面意思是信号量的意思，它的作用是控制访问特定资源的线程数目，底层依赖AQS的状态State，是在生产当中比较常用的一个工具类。

Semaphore是什么？

permits 表示许可线程的数量fair 表示公平性，如果这个设为 true 的话，下次执行的线程会是等待最久的线程

构造方法

acquire() 表示阻塞并获取许可release() 表示释放许可

重要方法

怎么使用 Semaphore？

资源访问，服务限流(Hystrix里限流就有基于信号量方式)。

需求场景

代码实现

Thread-3:aquire() at time:1563096128901Thread-1:aquire() at time:1563096128901Thread-1:aquire() at time:1563096129903Thread-7:aquire() at time:1563096129903Thread-5:aquire() at time:1563096129903Thread-3:aquire() at time:1563096129903Thread-7:aquire() at time:1563096130903Thread-5:aquire() at time:1563096130903Thread-9:aquire() at time:1563096130903Thread-9:aquire() at time:1563096131903

打印结果

从打印结果可以看出，一次只有两个线程执行 acquire()，只有线程进行 release() 方法后才会有别的线程执行 acquire()。

分析

基本使用

Semaphore

栅栏屏障，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续运行。

CyclicBarrier默认的构造方法是CyclicBarrier（int parties），其参数表示屏障拦截的线程数量，每个线程调用await方法告CyclicBarrier我已经到达了屏障，然后当前线程被阻塞。

cyclicBarrier.await();

可以用于多线程计算数据，最后合并计算结果的场景。例如，用一个Excel保存了用户所有银行流水，每个Sheet保存一个账户近一年的每笔银行流水，现在需要统计用户的日均银行流水，先用多线程处理每个sheet里的银行流水，都执行完之后，得到每个sheet的日均银行流水，最后，再用barrierAction用这些线程的计算结果，计算出整个Excel的日均银行流水。

应用场景

CyclicBarrier

当一个线程运行到exchange()方法时会阻塞，另一个线程运行到exchange()时，二者交换数据，然后执行后面的程序。

极少，了解即可

public class ExchangerTest { public static void main(String []args) { final Exchanger<Integer> exchanger = new Exchanger<Integer>(); for(int i = 0 ; i < 10 ; i++) { final Integer num = i; new Thread() { public void run() { System.out.println(\"我是线程：Thread_\" + this.getName() + \"我的数据是：\" + num); try { Integer exchangeNum = exchanger.exchange(num); Thread.sleep(1000); System.out.println(\"我是线程：Thread_\" + this.getName() + \"我原先的数据为：\" + num + \

Exchanger

线程协作

原子（atom）本意是“不能被进一步分割的最小粒子”，而原子操作（atomic operation）意为”不可被中断的一个或一系列操作” 。

原子操作

缓存的最小操作单位

缓存行（Cache line）

CAS操作需要输入两个数值，一个旧值（期望操作前的值）和一个新值，在操作期间先比较下在旧值有没有发生变化，如果没有发生变化，才交换成新值，发生了变化则不交换。

比较并交换（Compare and Swap）

CPU流水线的工作方式就象工业生产上的装配流水线，在CPU中由5~6个不同功能的电路单元组成一条指令处理流水线，然后将一条X86指令分成5~6步后再由这些电路单元分别执行，这样就能实现在一个CPU时钟周期完成一条指令，因此提高CPU的运算速度。

CPU流水线（CPU pipeline）

内存顺序冲突一般是由假共享引起，假共享是指多个CPU同时修改同一个缓存行的不同部分而引起其中一个CPU的操作无效，当出现这个内存顺序冲突时，CPU必须清空流水线。

内存顺序冲突（Memory order violation）

相关术语

32位IA-32处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。

首先处理器会自动保证基本的内存操作的原子性。处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。

处理器自动保证基本内存操作的原子性

使用总线锁保证原子性

原因是有可能多个处理器同时从各自的缓存中读取变量i，分别进行加一操作，然后分别写入系统内存当中。那么想要保证读改写共享变量的操作是原子的，就必须保证CPU1读改写共享变量的时候，CPU2不能操作缓存了该共享变量内存地址的缓存。

使用缓存锁保证原子性

处理器如何实现原子操作？

在java中可以通过锁和循环CAS的方式来实现原子操作

自旋CAS实现的基本思路就是循环进行CAS操作直到成功为止

Java当中如何实现原子操作？

在Atomic包里一共有12个类，四种原子更新方式，分别是原子更新基本类型，原子更新数组，原子更新引用和原子更新字段

Atomic包里的类基本都是使用Unsafe实现的包装类

原子更新布尔类型。

AtomicBoolean

原子更新整型。

常用方法

AtomicInteger

原子更新长整型。

AtomicLong

原子更新基本类型类

原子更新整型数组里的元素。

AtomicIntegerArray

原子更新长整型数组里的元素。

AtomicLongArray

原子更新引用类型数组里的元素。

AtomicReferenceArray

原子更新数组类

原子更新引用类型

AtomicReference

原子更新引用类型里的字段。

AtomicReferenceFieldUpdater

AtomicMarkableReference

原子更新整型的字段的更新器。

AtomicIntegerFieldUpdater

原子更新长整型字段的更新器。

AtomicLongFieldUpdater

原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于原子的更数据和数据的版本号，可以解决使用CAS进行原子更新时，可能出现的ABA问题。

AtomicStampedReference

原子更新字段类

四种更新方式

Atomic包里的类基本都是使用Unsafe实现的，Unsafe只提供了三种CAS方法，compareAndSwapObject，compareAndSwapInt和compareAndSwapLong，再看AtomicBoolean源码，发现其是先把Boolean转换成整型，再使用compareAndSwapInt进行CAS，所以原子更新double也可以用类似的思路来实现。

Atomic包提供了三种基本类型的原子更新，但是Java的基本类型里还有char，float和double等。那么问题来了，如何原子的更新其他的基本类型呢？

原子更新字段类都是抽象类，每次使用都时候必须使用静态方法newUpdater创建一个更新器。原子更新类的字段的必须使用public volatile修饰符。

Atomic

主要提供一些用于执行低级别、不安全操作的方法，如直接访问系统内存资源、自主管理内存资源等，这些方法在提升Java运行效率、增强Java语言底层资源操作能力方面起到了很大的作用。

但由于Unsafe类使Java语言拥有了类似C语言指针一样操作内存空间的能力，这无疑也增加了程序发生相关指针问题的风险。在程序中过度、不正确使用Unsafe类会使得程序出错的概率变大，使得Java这种安全的语言变得不再“安全”，因此对Unsafe的使用一定要慎重。

public class Unsafe { // 单例对象 private static final Unsafe theUnsafe; private Unsafe() { } @CallerSensitive public static Unsafe getUnsafe() { Class var0 = Reflection.getCallerClass(); // 仅在引导类加载器`BootstrapClassLoader`加载时才合法 if(!VM.isSystemDomainLoader(var0.getClassLoader())) { throw new SecurityException(\"Unsafe\"); } else { return theUnsafe; } }}

Unsafe类为一单例实现，提供静态方法getUnsafe获取Unsafe实例，当且仅当调用getUnsafe方法的类为引导类加载器所加载时才合法，否则抛出SecurityException异常。

从getUnsafe方法的使用限制条件出发，通过Java命令行命令-Xbootclasspath/a把调用Unsafe相关方法的类A所在jar包路径追加到默认的bootstrap路径中，使得A被引导类加载器加载，从而通过Unsafe.getUnsafe方法安全的获取Unsafe实例。java -Xbootclasspath/a:${path} // 其中path为调用Unsafe相关方法的类所在jar包路径

方式一

public class UnsafeInstance { public static Unsafe reflectGetUnsafe() { try { Field field = Unsafe.class.getDeclaredField(\"theUnsafe\"); field.setAccessible(true); return (Unsafe) field.get(null); } catch (Exception e) { e.printStackTrace(); } return null; }}

通过反射获取单例对象theUnsafe。

方式二

如何获取Unsafe实例？

Unsafe提供的API大致可分为内存操作、CAS、Class相关、对象操作、线程调度、系统信息获取、内存屏障、数组操作等几类，下面将对其相关方法和应用场景进行详细介绍

这部分主要包含堆外内存的分配、拷贝、释放、给定地址值操作等方法。

内存操作

如下源代码释义所示，这部分主要为CAS相关操作的方法。

详情查看链接

典型应用

CAS相关

包括线程挂起、恢复、锁机制等方法。

线程调度

//内存屏障，禁止load操作重排序。屏障前的load操作不能被重排序到屏障后，屏障后的load操作不能被重排序到屏障前public native void loadFence();//内存屏障，禁止store操作重排序。屏障前的store操作不能被重排序到屏障后，屏障后的store操作不能被重排序到屏障前public native void storeFence();//内存屏障，禁止load、store操作重排序public native void fullFence();

在Java 8中引入，用于定义内存屏障（也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。

内存屏障

常见几类

功能介绍

Unsafe应用解析

Atomic&Unsafe魔法类详解

原子操作类

线程池框架中最基础的部分，定义了一个用于执行Runnable的execute方法

履行Runnable类型的任务

execute(Runnable command)

提交Runnable或Callable类型的任务，并返回代表此任务的Future对象

submit（task)

在完成已提交的任务封闭办事，不再接管新任务

shutdown（）

停止所有正在履行的任务封闭办事

shutdownNow()

测试是否所有任务都履行完毕了

isTerminated()

测试是否该ExecutorService已被关闭

isShutdown()

Executor的一个重要子接口，定义了线程池的具体行为

ExecutorService

创建

1、public void execute() //提交任务无返回值2、public Future<?> submit() //任务执行完成后有返回值

任务提交

ThreadPoolExecutor（默认线程池）

ScheduledThreadPoolExecutor（定时线程池）

线程池的具体实现

主要用来创建线程池，代理了线程池的创建，使得你的创建入口参数变得简单

创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

newCachedThreadPool

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

newFixedThreadPool

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

newScheduledThreadPool

newSingleThreadExecutor

Executors

Executor框架

ConcurrentHashMap

ConcurrentSkipListMap

Map

CopyOnWriteArrayList

List

CopyOnWriteArraySet

ConcurrentSkipListSet

Set

ArrayBlockingQueue

LinkedBlockingQueue

SynchronousQueue

PriorityBlockingQueue

DelayQueue

LinkedTransferQueue

BlockingQueue

ConcurrentLinkedQueue

BlockingDeque

ConcurrentLinkedDeque

Queue

并发容器

FutureTask

CompletableFuture

Future

是 Java7 提供了的一个用于并行执行任务的框架

是一个把大任务分割成若干个小任务，最终汇总每个小任务结果后得到大任务结果的框架

比如计算1+2+.....＋10000，可以分割成 10 个子任务，每个子任务分别对 1000 个数进行求和，最终汇总这 10 个子任务的结果。如下图所示：

什么是 Fork/Join 框架？

ForkJoinPool 不是为了替代 ExecutorService，而是它的补充，在某些应用场景下性能比 ExecutorService 更好。（见 Java Tip: When to use ForkJoinPool vs ExecutorService ）

ForkJoinPool 主要用于实现“分而治之”的算法，特别是分治之后递归调用的函数，例如 quick sort 等。

ForkJoinPool 最适合的是计算密集型的任务，如果存在 I/O，线程间同步，sleep() 等会造成线程长时间阻塞的情况时，最好配合使用 ManagedBlocker。

Fork/Jion特性：

是指某个线程从其他队列里窃取任务来执行

我们需要做一个比较大的任务，我们可以把这个任务分割为若干互不依赖的子任务，为了减少线程间的竞争，于是把这些子任务分别放到不同的队列里，并为每个队列创建一个单独的线程来执行队列里的任务，线程和队列一一对应，比如A线程负责处理A队列里的任务。但是有的线程会先把自己队列里的任务干完，而其他线程对应的队列里还有任务等待处理。干完活的线程与其等着，不如去帮其他线程干活，于是它就去其他线程的队列里窃取一个任务来执行。而在这时它们会访问同一个队列，所以为了减少窃取任务线程和被窃取任务线程之间的竞争，通常会使用双端队列，被窃取任务线程永远从双端队列的头部拿任务执行，而窃取任务的线程永远从双端队列的尾部拿任务执行

工作窃取算法的优点是充分利用线程进行并行计算，并减少了线程间的竞争，其缺点是在某些情况下还是存在竞争，比如双端队列里只有一个任务时。并且消耗了更多的系统资源，比如创建多个线程和多个双端队列。

ForkJoinPool 的每个工作线程都维护着一个工作队列（WorkQueue），这是一个双端队列（Deque），里面存放的对象是任务（ForkJoinTask）。每个工作线程在运行中产生新的任务（通常是因为调用了 fork()）时，会放入工作队列的队尾，并且工作线程在处理自己的工作队列时，使用的是 LIFO 方式，也就是说每次从队尾取出任务来执行。每个工作线程在处理自己的工作队列同时，会尝试窃取一个任务（或是来自于刚刚提交到 pool 的任务，或是来自于其他工作线程的工作队列），窃取的任务位于其他线程的工作队列的队首，也就是说工作线程在窃取其他工作线程的任务时，使用的是 FIFO 方式。在遇到 join() 时，如果需要 join 的任务尚未完成，则会先处理其他任务，并等待其完成。在既没有自己的任务，也没有可以窃取的任务时，进入休眠。

工作窃取算法

用于没有返回结果的任务。(比如写数据到磁盘，然后就退出了。一个RecursiveAction可以把自己的工作分割成更小的几块，这样它们可以由独立的线程或者CPU执行。我们可以通过继承来实现一个RecursiveAction)

ecursiveAction

用于有返回结果的任务。(可以将自己的工作分割为若干更小任务，并将这些子任务的执行合并到一个集体结果。可以有几个水平的分割和合并)

RecursiveTask

我们要使用 ForkJoin 框架，必须首先创建一个 ForkJoin 任务。它提供在任务中执行 fork() 和 join() 操作的机制，通常情况下我们不需要直接继承 ForkJoinTask 类，而只需要继承它的子类，Fork/Join 框架提供了以下两个子类：

ForkJoinTask

在任务完成执行后会触发执行一个自定义的钩子函数

CountedCompleter

ForkJoinTask 需要通过 ForkJoinPool 来执行，任务分割出的子任务会添加到当前工作线程所维护的双端队列中，进入队列的头部。当一个工作线程的队列里暂时没有任务时，它会随机从其他工作线程的队列的尾部获取一个任务。

ForkJoinPool

fork/join的使用

多核、多内存、可以分割计算再合并的计算密集型任务

定义fork/join任务，如下示例，随机生成2000w条数据在数组当中，然后求和

使用场景示例：

最佳应用场景

常量介绍

异常处理

ForkJoinPool构造函数

ForkJoinTask fork 方法

ForkJoinTask join 方法

ForkJoinPool.submit 方法

Fork/Join框架执行流程

fork/join框架原理（详情查看上述链接）

Fork/Join 框架

无锁并发框架-Disruptor

Doug Lea(小名：李二狗)

生平不识Doug Lea，学懂并发也枉然

并发之父

Java并发编程核心在于java.util.concurrent包而juc当中的大多数同步器实现都是围绕着共同的基础行为，比如等待队列、条件队列、独占获取、共享获取等，而这个行为的抽象就是基于AbstractQueuedSynchronizer简称AQS，AQS定义了一套多线程访问共享资源的同步器框架，是一个依赖状态(state)的同步器。

ReentrantLock是一种基于AQS框架的应用实现，是JDK中的一种线程并发访问的同步手段，它的功能类似于synchronized是一种互斥锁，可以保证线程安全。而且它具有比synchronized更多的特性，比如它支持手动加锁与解锁，支持加锁的公平性。

使用ReentrantLock进行同步ReentrantLock lock = new ReentrantLock(false);//false为非公平锁，true为公平锁lock.lock() //加锁lock.unlock() //解锁

代码

在ReentrantLock内部定义了一个Sync的内部类，该类继承AbstractQueuedSynchronized，对该抽象类的部分方法做了实现；并且还定义了两个子类：1、FairSync 公平锁的实现2、NonfairSync 非公平锁的实现这两个类都继承自Sync，也就是间接继承了AbstractQueuedSynchronized，所以这一个ReentrantLock同时具备公平与非公平特性。上面主要涉及的设计模式：模板模式-子类根据需要做具体业务实现

ReentrantLock如何实现synchronized不具备的公平与非公平性呢？

ReentrantLock

阻塞等待队列

共享/独占

公平/非公平

可重入

允许中断

AQS具备特性

state表示资源的可用状态

getState()

setState()

compareAndSetState()

State三种访问方式

AQS内部维护属性volatile int state (32位)

Exclusive-独占，只有一个线程能执行，如ReentrantLock

Share-共享，多个线程可以同时执行，如Semaphore/CountDownLatch

AQS定义两种资源共享方式

同步等待队列

条件等待队列

AQS定义两种队列

isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

自定义同步器实现时主要实现以下几种方法：

AQS源码分析

AQS应用之Lock

是java.util.concurrent 包提供的用于解决并发生产者 - 消费者问题的最有用的类，它的特性是在任意时刻只有一个线程可以进行take或者put操作，并且BlockingQueue提供了超时return null的机制，在许多生产场景里都可以看到这个工具的身影。

如果插入成功则返回 true，否则抛出 IllegalStateException 异常

add()

将指定的元素插入队列，如果队列满了，那么会阻塞直到有空间插入

put()

如果插入成功则返回 true，否则返回 false

offer()

如果当前队列中元素的数量等于队列的容量，则在规定时间内会一直阻塞，如果超过了规定时间则直接返回false

添加元素

获取队列的头部元素并将其删除，如果队列为空，则阻塞并等待元素变为可用

take()

检索并删除队列的头部，如有必要，等待指定的等待时间以使元素可用，如果超时，则返回 null

检索元素

api

多线程生产者-消费者示例

几乎可以无限增长

无限队列（unbounded queue ）

定义了最大容量

有限队列（ bounded queue ）

队列类型

队列实质就是一种存储数据的结构

通常用链表或者数组实现

一般而言队列具备FIFO先进先出的特性，当然也有双端队列（Deque）优先级队列

主要操作：入队（EnQueue）与出队（Dequeue）

队列数据结构

由数组支持的有界队列

ArrayBlockingQueue

由链接节点支持的可选有界队列

LinkedBlockingQueue

由优先级堆支持的无界优先级队列

PriorityBlockingQueue

由优先级堆支持的、基于时间的调度队列

DelayQueue

常见的4种阻塞队列

数据结构如下图：

BlockingQueue<String> blockingQueue = new ArrayBlockingQueue<>();

队列创建：

在线程池中有比较多的应用，生产者消费者场景

基于ReentrantLock保证线程安全，根据Condition实现队列满时的阻塞

工作原理

是一个基于链表的无界队列(理论上有界)

BlockingQueue<String> blockingQueue = new LinkedBlockingQueue<>();

创建方式

上面这段代码中，blockingQueue 的容量将设置为 Integer.MAX_VALUE 。

向无限队列添加元素的所有操作都将永远不会阻塞，[注意这里不是说不会加锁保证线程安全]，因此它可以增长到非常大的容量。

使用无限 BlockingQueue 设计生产者 - 消费者模型时最重要的是消费者应该能够像生产者向队列添加消息一样快地消费消息。否则，内存可能会填满，然后就会得到一个 OutOfMemory 异常。

解析

由优先级堆支持的、基于时间的调度队列，内部基于无界队列PriorityQueue实现，而无界队列基于数组的扩容实现。

BlockingQueue<String> blockingQueue = new DelayQueue();

要求

电影票

队列内部会根据时间优先级进行排序。延迟类线程池周期执行。

工作原理：

同步器AQS应用之BlockingQueue详解

AQS同步器

并发工具类

无锁

有锁

线程安全问题解决方案

并发编程

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(\"spring.xml\");UserService userService = (UserService) context.getBean(\"userService\");userService.test();

xml配置的方式（已过时）

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);UserService userService = (UserService) context.getBean(\"userService\");userService.test();

注解的方式（SpringMVC、SpringBoot主要用的方式）

构建上下文并获取bean方式

<context:component-scan base-package=\"com.zhouyu\"/><bean id=\"userService\" class=\"com.zhouyu.service.UserService\"/>

xml配置bean

@ComponentScan(\"com.zhouyu\")public class AppConfig { @Bean public UserService userService(){ return new UserService(); }}

注解配置bean

不同方式在配置bean上的区别

入门

font color=\"#ff0000\

Spring中是如何创建一个对象？

那么Spring到底是如何来创建一个Bean的呢，这个就是Bean创建的生命周期，大致过程如下利用该类的构造方法来实例化得到一个对象（但是如何一个类中有多个构造方法，Spring则会进行选择，这个叫做推断构造方法）得到一个对象后，Spring会判断该对象中是否存在被@Autowired注解了的属性，把这些属性找出来并由Spring进行赋值（依赖注入）依赖注入后，Spring会判断该对象是否实现了BeanNameAware接口、BeanClassLoaderAware接口、BeanFactoryAware接口，如果实现了，就表示当前对象必须实现该接口中所定义的setBeanName()、setBeanClassLoader()、setBeanFactory()方法，那Spring就会调用这些方法并传入相应的参数（Aware回调）Aware回调后，Spring会判断该对象中是否存在某个方法被@PostConstruct注解了，如果存在，Spring会调用当前对象的此方法（初始化前）紧接着，Spring会判断该对象是否实现了InitializingBean接口，如果实现了，就表示当前对象必须实现该接口中的afterPropertiesSet()方法，那Spring就会调用当前对象中的afterPropertiesSet()方法（初始化）最后，Spring会判断当前对象需不需要进行AOP，如果不需要那么Bean就创建完了，如果需要进行AOP，则会进行动态代理并生成一个代理对象做为Bean（初始化后）通过最后一步，我们可以发现，当Spring根据UserService类来创建一个Bean时：如果不用进行AOP，那么Bean就是UserService类的构造方法所得到的对象。如果需要进行AOP，那么Bean就是UserService的代理类所实例化得到的对象，而不是UserService本身所得到的对象。Bean对象创建出来后：font color=\"#f57f17\

Bean的创建过程

概念：确定用哪个构造方法，确定入参的Bean对象，这个过程就叫做推断构造方法。

如果一个类只存在一个构造方法，不管该构造方法是无参构造方法，还是有参构造方法，Spring都会用这个构造方法如果一个类存在多个构造方法： 1.这些构造方法中，存在一个无参的构造方法，那么Spring就会用这个无参的构造方法 2.这些构造方法中，不存在一个无参的构造方法，那么Spring就会报错

Spring的判断逻辑

如果一个类只有一个构造方法，那么没得选择，只能用这个构造方法如果一个类存在多个构造方法，Spring不知道如何选择，就会看是否有无参的构造方法，因为无参构造方法本身表示了一种默认的意义不过如果某个构造方法上加了@Autowired注解，那就表示程序员告诉Spring就用这个加了注解的方法，那Spring就会用这个加了@Autowired注解构造方法了

Spring的设计思想

Spring在基于某个类生成Bean的过程中，需要利用该类的构造方法来实例化得到一个对象，但是如果一个类存在多个构造方法，Spring会使用哪个呢？

Spring会根据入参的类型和入参的名字去Spring中找Bean对象（以单例Bean为例，Spring会从单例池那个Map中去找）：先根据入参类型找，如果只找到一个，那就直接用来作为入参如果根据类型找到多个，则再根据入参名字来确定唯一一个最终如果没有找到，则会报错，无法创建当前Bean对象

需要重视的是，如果Spring选择了一个有参的构造方法，Spring在调用这个有参构造方法时，需要传入参数，那这个参数是怎么来的呢？

推断构造方法

AOP就是进行动态代理，在创建一个Bean的过程中，Spring在最后一步会去判断当前正在创建的这个Bean是不是需要进行AOP，如果需要则会进行动态代理

找出所有的切面Bean遍历切面中的每个方法，看是否写了@Before、@After等注解如果写了，则判断所对应的Pointcut是否和当前Bean对象的类是否匹配如果匹配则表示当前Bean对象有匹配的的Pointcut，表示需要进行AOP

如何判断当前Bean对象需不需要进行AOP

生成代理类UserServiceProxy，代理类继承UserService代理类中重写了父类的方法，比如UserService中的test()方法代理类中还会有一个target属性，该属性的值为被代理对象（也就是通过UserService类推断构造方法实例化出来的对象，进行了依赖注入、初始化等步骤的对象）代理类中的test()方法被执行时的逻辑如下：执行切面逻辑（@Before）调用target.test()

利用cglib进行AOP的大致流程

当我们从Spring容器得到UserService的Bean对象时，拿到的就是UserServiceProxy所生成的对象，也就是代理对象。UserService代理对象.test()--->执行切面逻辑--->target.test()，注意target对象不是代理对象，而是被代理对象。

AOP大致流程

当我们在某个方法上加了@Transactional注解后，就表示该方法在调用时会开启Spring事务，而这个方法所在的类所对应的Bean对象会是该类的代理对象

判断当前执行的方法是否存在@Transactional注解如果存在，则利用事务管理器（TransactionMananger）新建一个数据库连接修改数据库连接的autocommit为false执行target.test()，执行程序员所写的业务逻辑代码，也就是执行sql执行完了之后如果没有出现异常，则提交，否则回滚

Spring事务的代理对象执行某个方法时的步骤

某个加了@Transactional注解的方法被调用时，要判断到底是不是直接是代理对象调用的，如果是则事务会生效，如果不是则失效。

Spring事务是否会失效的判断标准

Spring事务

核心原理解析

class，表示Bean类型scope，表示Bean作用域，单例或原型等lazyInit：表示Bean是否是懒加载initMethodName：表示Bean初始化时要执行的方法destroyMethodName：表示Bean销毁时要执行的方法还有很多...

BeanDefinition表示Bean定义，BeanDefinition中存在很多属性用来描述一个Bean的特点，比如：

申明式定义Bean

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);// 生成一个BeanDefinition对象，并设置beanClass为User.class，并注册到ApplicationContext中AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.genericBeanDefinition().getBeanDefinition();beanDefinition.setBeanClass(User.class);context.registerBeanDefinition(\"user\

我们还可以通过BeanDefinition设置一个Bean的其他属性beanDefinition.setScope(\"prototype\"); // 设置作用域beanDefinition.setInitMethodName(\"init\"); // 设置初始化方法beanDefinition.setLazyInit(true); // 设置懒加载

编程式定义Bean（直接通过BeanDefinition）

（延伸）bean定义的两种方式

BeanDefinition

和申明式事务、编程式事务类似，通过<bean/>，@Bean，@Component等申明式方式所定义的Bean，最终都会被Spring解析为对应的BeanDefinition对象，并放入Spring容器中。

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);AnnotatedBeanDefinitionReader annotatedBeanDefinitionReader = new AnnotatedBeanDefinitionReader(context);// 将User.class解析为BeanDefinitionannotatedBeanDefinitionReader.register(User.class);System.out.println(context.getBean(\"user\"));

可以直接把某个类转换为BeanDefinition，并且会解析该类上的注解，比如

注意：它能解析的注解是：@Conditional，@Scope、@Lazy、@Primary、@DependsOn、@Role、@Description

AnnotatedBeanDefinitionReader

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);XmlBeanDefinitionReader xmlBeanDefinitionReader = new XmlBeanDefinitionReader(context);int i = xmlBeanDefinitionReader.loadBeanDefinitions(\"spring.xml\");System.out.println(context.getBean(\"user\"));

可以解析<bean/>标签

XmlBeanDefinitionReader

介绍几种在Spring源码中所提供的BeanDefinition读取器，Spring源码中用得多，相当于Spring源码的基础设施

BeanDefinitionReader

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();context.refresh();ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(context);scanner.scan(\"com.zhouyu\");System.out.println(context.getBean(\"userService\"));

ClassPathBeanDefinitionScanner是扫描器，但是它的作用和BeanDefinitionReader类似，它可以进行扫描，扫描某个包路径，对扫描到的类进行解析，比如，扫描到的类上如果存在@Component注解，那么就会把这个类解析为一个BeanDefinition

ClassPathBeanDefinitionScanner

BeanFactory表示Bean工厂，所以很明显，BeanFactory会负责创建Bean，并且提供获取Bean的API。

ApplicationContext是BeanFactory的一种，在Spring源码中，是这么定义的

DefaultListableBeanFactory beanFactory = new DefaultListableBeanFactory();AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.genericBeanDefinition().getBeanDefinition();beanDefinition.setBeanClass(User.class);beanFactory.registerBeanDefinition(\"user\

BeanFactory接口存在一个非常重要的实现类是：**DefaultListableBeanFactory。所以，我们可以直接来使用DefaultListableBeanFactory，而不用使用ApplicationContext的某个实现类

AliasRegistry：支持别名功能，一个名字可以对应多个别名BeanDefinitionRegistry：可以注册、保存、移除、获取某个BeanDefinitionBeanFactory：Bean工厂，可以根据某个bean的名字、或类型、或别名获取某个Bean对象SingletonBeanRegistry：可以直接注册、获取某个单例BeanSimpleAliasRegistry：它是一个类，实现了AliasRegistry接口中所定义的功能，支持别名功能ListableBeanFactory：在BeanFactory的基础上，增加了其他功能，可以获取所有BeanDefinition的beanNames，可以根据某个类型获取对应的beanNames，可以根据某个类型获取{类型：对应的Bean}的映射关系HierarchicalBeanFactory：在BeanFactory的基础上，添加了获取父BeanFactory的功能DefaultSingletonBeanRegistry：它是一个类，实现了SingletonBeanRegistry接口，拥有了直接注册、获取某个单例Bean的功能ConfigurableBeanFactory：在HierarchicalBeanFactory和SingletonBeanRegistry的基础上，添加了设置父BeanFactory、类加载器（表示可以指定某个类加载器进行类的加载）、设置Spring EL表达式解析器（表示该BeanFactory可以解析EL表达式）、设置类型转化服务（表示该BeanFactory可以进行类型转化）、可以添加BeanPostProcessor（表示该BeanFactory支持Bean的后置处理器），可以合并BeanDefinition，可以销毁某个Bean等等功能FactoryBeanRegistrySupport：支持了FactoryBean的功能AutowireCapableBeanFactory：是直接继承了BeanFactory，在BeanFactory的基础上，支持在创建Bean的过程中能对Bean进行自动装配AbstractBeanFactory：实现了ConfigurableBeanFactory接口，继承了FactoryBeanRegistrySupport，这个BeanFactory的功能已经很全面了，但是不能自动装配和获取beanNamesConfigurableListableBeanFactory：继承了ListableBeanFactory、AutowireCapableBeanFactory、ConfigurableBeanFactoryAbstractAutowireCapableBeanFactory：继承了AbstractBeanFactory，实现了AutowireCapableBeanFactory，拥有了自动装配的功能DefaultListableBeanFactory：继承了AbstractAutowireCapableBeanFactory，实现了ConfigurableListableBeanFactory接口和BeanDefinitionRegistry接口，所以DefaultListableBeanFactory的功能很强大

DefaultListableBeanFactory是非常强大的，支持很多功能，可以通过查看DefaultListableBeanFactory的类继承实现结构来看。它实现了很多接口，表示，它拥有很多功能：

@Componentpublic class ZhouyuFactoryBean implements FactoryBean { @Override public Object getObject() throws Exception { UserService userService = new UserService(); return userService; } @Override public Class<?> getObjectType() { return UserService.class; }}

通过上面这段代码，我们自己创造了一个UserService对象，并且它将成为Bean。但是通过这种方式创造出来的UserService的Bean，只会经过初始化后，其他Spring的生命周期步骤是不会经过的，比如依赖注入。

其实在很多场景下他俩是可以替换的，但是站在原理层面来说的，区别很明显，@Bean定义的Bean是会经过完整的Bean生命周期的

通过@Bean也可以自己生成一个对象作为Bean，那么和FactoryBean的区别是什么呢？

如果我们想一个Bean完完全全由我们来创造，也是可以的，比如通过FactoryBean

BeanFactory

首先，在Java中，接口是可以多继承的，我们发现ApplicationContext继承了ListableBeanFactory和HierarchicalBeanFactory，而ListableBeanFactory和HierarchicalBeanFactory都继承至BeanFactory，所以我们可以认为ApplicationContext继承了BeanFactory，相当于苹果继承水果，宝马继承汽车一样，ApplicationContext也是BeanFactory的一种，拥有BeanFactory支持的所有功能，不过ApplicationContext比BeanFactory更加强大，ApplicationContext还基础了其他接口，也就表示ApplicationContext还拥有其他功能，比如MessageSource表示国际化，ApplicationEventPublisher表示事件发布，EnvironmentCapable表示获取环境变量，等等，关于ApplicationContext后面再详细讨论。在Spring的源码实现中，当我们new一个ApplicationContext时，其底层会new一个BeanFactory出来，当使用ApplicationContext的某些方法时，比如getBean()，底层调用的是BeanFactory的getBean()方法。

HierarchicalBeanFactory：拥有获取父BeanFactory的功能ListableBeanFactory：拥有获取beanNames的功能ResourcePatternResolver：资源加载器，可以一次性获取多个资源（文件资源等等）EnvironmentCapable：可以获取运行时环境（没有设置运行时环境功能）ApplicationEventPublisher：拥有广播事件的功能（没有添加事件监听器的功能）MessageSource：拥有国际化功能

上面有分析到，ApplicationContext是个接口，实际上也是一个BeanFactory，不过比BeanFactory更加强大，比如：

ConfigurableApplicationContext：继承了ApplicationContext接口，增加了，添加事件监听器、添加BeanFactoryPostProcessor、设置Environment，获取ConfigurableListableBeanFactory等功能AbstractApplicationContext：实现了ConfigurableApplicationContext接口GenericApplicationContext：继承了AbstractApplicationContext，实现了BeanDefinitionRegistry接口，拥有了所有ApplicationContext的功能，并且可以注册BeanDefinition，注意这个类中有一个属性(DefaultListableBeanFactory beanFactory)AnnotationConfigRegistry：可以单独注册某个为类为BeanDefinition（可以处理该类上的**@Configuration注解**，已经可以处理**@Bean注解**），同时可以扫描AnnotationConfigApplicationContext：继承了GenericApplicationContext，实现了AnnotationConfigRegistry接口，拥有了以上所有的功能

AnnotationConfigApplicationContext

它也是继承了AbstractApplicationContext，但是相对于AnnotationConfigApplicationContext而言，功能没有AnnotationConfigApplicationContext强大，比如不能注册BeanDefinition

ClassPathXmlApplicationContext

ApplicationContext两个比较重要的实现类

ApplicationContext

@Beanpublic MessageSource messageSource() { ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource(); messageSource.setBasename(\"messages\"); return messageSource;}

先定义一个MessageSource:

context.getMessage(\"test\

有了这个Bean，你可以在你任意想要进行国际化的地方使用该MessageSource。同时，因为ApplicationContext也拥有国家化的功能，所以可以直接这么用：

国际化

ApplicationContext还拥有资源加载的功能，比如，可以直接利用ApplicationContext获取某个文件的内容

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);Resource resource = context.getResource(\"file://D:\\\\IdeaProjects\\\\spring-framework-5.3.10\\\\tuling\\\\src\\\\main\\\\java\\\\com\\\\zhouyu\\\\service\\\\UserService.java\");System.out.println(resource.contentLength());System.out.println(resource.getFilename());Resource resource1 = context.getResource(\"https://www.baidu.com\");System.out.println(resource1.contentLength());System.out.println(resource1.getURL());Resource resource2 = context.getResource(\"classpath:spring.xml\");System.out.println(resource2.contentLength());System.out.println(resource2.getURL());

资源加载的几种方式

Resource[] resources = context.getResources(\"classpath:com/zhouyu/*.class\");for (Resource resource : resources) { System.out.println(resource.contentLength()); System.out.println(resource.getFilename());}

还可以一次性获取多个：

资源加载

@PropertySource(\"classpath:spring.properties\")

注意，可以利用来使得某个properties文件中的参数添加到运行时环境中

获取运行时环境

@Beanpublic ApplicationListener applicationListener() { return new ApplicationListener() { @Override public void onApplicationEvent(ApplicationEvent event) { System.out.println(\"接收到了一个事件\"); } };}

先定义一个事件监听器

context.publishEvent(\"kkk\");

然后发布一个事件

事件发布

在Spring源码中，有可能需要把String转成其他类型，所以在Spring源码中提供了一些技术来更方便的做对象的类型转化，关于类型转化的应用场景，后续看源码的过程中会遇到很多。

这其实是JDK中提供的类型转化工具类

public class StringToUserPropertyEditor extends PropertyEditorSupport implements PropertyEditor { @Override public void setAsText(String text) throws IllegalArgumentException { User user = new User(); user.setName(text); this.setValue(user); }}

定义转换器

StringToUserPropertyEditor propertyEditor = new StringToUserPropertyEditor();propertyEditor.setAsText(\"1\");User value = (User) propertyEditor.getValue();System.out.println(value);

使用

如何向Spring中注册PropertyEditor

@Componentpublic class UserService { @Value(\"xxx\") private User user; public void test() { System.out.println(user); }}

假设现在有如下Bean，那么test属性就能正常的完成属性赋值

PropertyEditor

Spring中提供的类型转化服务，它比PropertyEditor更强大

定义

DefaultConversionService conversionService = new DefaultConversionService();conversionService.addConverter(new StringToUserConverter());User value = conversionService.convert(\"1\

@Beanpublic ConversionServiceFactoryBean conversionService() { ConversionServiceFactoryBean conversionServiceFactoryBean = new ConversionServiceFactoryBean(); conversionServiceFactoryBean.setConverters(Collections.singleton(new StringToUserConverter())); return conversionServiceFactoryBean;}

如何向Spring中注册ConversionService

ConversionService

整合了PropertyEditor和ConversionService的功能，是Spring内部用的

TypeConverter

类型转化

OrderComparator是Spring所提供的一种比较器，可以用来根据@Order注解或实现Ordered接口来执行值进行笔记，从而可以进行排序。

public class A implements Ordered { @Override public int getOrder() { return 3; } @Override public String toString() { return this.getClass().getSimpleName(); }}

public class B implements Ordered { @Override public int getOrder() { return 2; } @Override public String toString() { return this.getClass().getSimpleName(); }}

示例

OrderComparator的子类，它支持用@Order来指定order值

@Order(3)public class A { @Override public String toString() { return this.getClass().getSimpleName(); }}

@Order(2)public class B { @Override public String toString() { return this.getClass().getSimpleName(); }}

AnnotationAwareOrderComparator

OrderComparator

BeanPostProcess表示Bena的后置处理器，我们可以定义一个或多个BeanPostProcessor

一个BeanPostProcessor可以在任意一个Bean的初始化之前以及初始化之后去额外的做一些用户自定义的逻辑，当然，我们可以通过判断beanName来进行针对性处理（针对某个Bean，或某部分Bean）。我们可以通过定义BeanPostProcessor来干涉Spring创建Bean的过程。

BeanPostProcessor

BeanFactoryPostProcessor表示Bean工厂的后置处理器，其实和BeanPostProcessor类似，BeanPostProcessor是干涉Bean的创建过程，BeanFactoryPostProcessor是干涉BeanFactory的创建过程

@Componentpublic class ZhouyuBeanFactoryPostProcessor implements BeanFactoryPostProcessor { @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { System.out.println(\"加工beanFactory\"); }}

我们可以在postProcessBeanFactory()方法中对BeanFactory进行加工。

BeanFactoryPostProcessor

这两个Filter是Spring扫描过程中用来过滤的。ExcludeFilter表示排除过滤器，IncludeFilter表示包含过滤器。

@ComponentScan(value = \"com.zhouyu\

比如以下配置，表示扫描com.zhouyu这个包下面的所有类，但是排除UserService类，也就是就算它上面有@Component注解也不会成为Bean。

再比如以下配置，就算UserService类上没有@Component注解，它也会被扫描成为一个Bean。

ANNOTATION：表示是否包含某个注解

ASSIGNABLE_TYPE：表示是否是某个类

ASPECTJ：表示否是符合某个Aspectj表达式

REGEX：表示是否符合某个正则表达式

CUSTOM：自定义

FilterType分为

在Spring的扫描逻辑中，默认会添加一个AnnotationTypeFilter给includeFilters，表示默认情况下Spring扫描过程中会认为类上有@Component注解的就是Bean。

ExcludeFilter和IncludeFilter

在Spring中需要去解析类的信息，比如类名、类中的方法、类上的注解，这些都可以称之为类的元数据，所以Spring中对类的元数据做了抽象，并提供了一些工具类。

public class Test { public static void main(String[] args) throws IOException { SimpleMetadataReaderFactory simpleMetadataReaderFactory = new SimpleMetadataReaderFactory(); // 构造一个MetadataReader MetadataReader metadataReader = simpleMetadataReaderFactory.getMetadataReader(\"com.zhouyu.service.UserService\"); // 得到一个ClassMetadata，并获取了类名 ClassMetadata classMetadata = metadataReader.getClassMetadata(); System.out.println(classMetadata.getClassName()); // 获取一个AnnotationMetadata，并获取类上的注解信息 AnnotationMetadata annotationMetadata = metadataReader.getAnnotationMetadata(); for (String annotationType : annotationMetadata.getAnnotationTypes()) { System.out.println(annotationType); } }}

MetadataReader表示类的元数据读取器，默认实现类为SimpleMetadataReader

需要注意的是，SimpleMetadataReader去解析类时，使用的ASM技术

Spring启动的时候需要去扫描，如果指定的包路径比较宽泛，那么扫描的类是非常多的，那如果在Spring启动时就把这些类全部加载进JVM了，这样不太好，所以使用了ASM技术。

为什么要使用ASM技术

MetadataReader、ClassMetadata、AnnotationMetadata

核心概念解析

Spring启动的时候会进行扫描，会先调用org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider#scanCandidateComponents(String basePackage) 扫描某个包路径，并得到BeanDefinition的Set集合

首先，通过ResourcePatternResolver获得指定包路径下的所有.class文件（Spring源码中将此文件包装成了Resource对象）遍历每个Resource对象利用MetadataReaderFactory解析Resource对象得到MetadataReader（在Spring源码中MetadataReaderFactory具体的实现类为CachingMetadataReaderFactory，MetadataReader的具体实现类为SimpleMetadataReader）利用MetadataReader进行excludeFilters和includeFilters，以及条件注解@Conditional的筛选（条件注解并不能理解：某个类上是否存在@Conditional注解，如果存在则调用注解中所指定的类的match方法进行匹配，匹配成功则通过筛选，匹配失败则pass掉。）筛选通过后，基于metadataReader生成ScannedGenericBeanDefinition再基于metadataReader判断是不是对应的类是不是接口或抽象类如果筛选通过，那么就表示扫描到了一个Bean，将ScannedGenericBeanDefinition加入结果集

Spring扫描的底层实现

表示类的元数据读取器，主要包含了一个AnnotationMetadata

获取类的名字、获取父类的名字获取所实现的所有接口名获取所有内部类的名字判断是不是抽象类判断是不是接口判断是不是一个注解获取拥有某个注解的方法集合获取类上添加的所有注解信息获取类上添加的所有注解类型集合

主要功能

MetadataReader

值得注意的是，CachingMetadataReaderFactory解析某个.class文件得到MetadataReader对象是利用的ASM技术，并没有加载这个类到JVM。并且，最终得到的ScannedGenericBeanDefinition对象，beanClass属性存储的是当前类的名字，而不是class对象。（beanClass属性的类型是Object，它即可以存储类的名字，也可以存储class对象）

最后，上面是说的通过扫描得到BeanDefinition对象，我们还可以通过直接定义BeanDefinition，或解析spring.xml文件的<bean/>，或者@Bean注解得到BeanDefinition对象

1. 生成BeanDefinition

通过扫描得到所有BeanDefinition之后，就可以根据BeanDefinition创建Bean对象了，但是在Spring中支持父子BeanDefinition，和Java父子类类似，但是完全不是一回事

父子BeanDefinition实际用的比较少，使用是这样的，比如

这么定义的情况下，child是单例Bean

但是这么定义的情况下，child就是原型Bean了因为child的父BeanDefinition是parent，所以会继承parent上所定义的scope属性。而在根据child来生成Bean对象之前，需要进行BeanDefinition的合并，得到完整的child的BeanDefinition

2. 合并BeanDefinition

public boolean hasBeanClass() { return (this.beanClass instanceof Class);}

这行代码就是去加载类，该方法是这么实现的

BeanDefinition合并之后，就可以去创建Bean对象了，而创建Bean就必须实例化对象，而实例化就必须先加载当前BeanDefinition所对应的class，在AbstractAutowireCapableBeanFactory类的createBean()方法中，一开始就会调用：

如果beanClass属性的类型是Class，那么就直接返回，如果不是，则会根据类名进行加载（doResolveBeanClass方法所做的事情）会利用BeanFactory所设置的类加载器来加载类，如果没有设置，则默认使用**ClassUtils.getDefaultClassLoader()**所返回的类加载器来加载。

ClassUtils.getDefaultClassLoader()优先返回当前线程中的ClassLoader线程中类加载器为null的情况下，返回ClassUtils类的类加载器如果ClassUtils类的类加载器为空，那么则表示是Bootstrap类加载器加载的ClassUtils类，那么则返回系统类加载器

概要

3. 加载类

如上代码会导致，在userService这个Bean实例化前，会进行打印。值得注意的是，postProcessBeforeInstantiation()是有返回值的，如果这么实现：

userService这个Bean，在实例化前会直接返回一个由我们所定义的UserService对象。如果是这样，表示不需要Spring来实例化了，并且后续的Spring依赖注入也不会进行了，会跳过一些步骤，直接执行初始化后这一步。

当前BeanDefinition对应的类成功加载后，就可以实例化对象了，但是...在Spring中，实例化对象之前，Spring提供了一个扩展点，允许用户来控制是否在某个或某些Bean实例化之前做一些启动动作。这个扩展点叫InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation()。比如

4. 实例化前

在这个步骤中就会根据BeanDefinition去创建一个对象了

首先判断BeanDefinition中是否设置了Supplier，如果设置了则调用Supplier的get()得到对象。

AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.genericBeanDefinition().getBeanDefinition();beanDefinition.setInstanceSupplier(new Supplier<Object>() { @Override public Object get() { return new UserService(); }});context.registerBeanDefinition(\"userService\

直接使用BeanDefinition对象来设置Supplier，比如：

5.1 Supplier创建对象

public class UserService { public static UserService createUserService() { System.out.println(\"执行createUserService()\"); UserService userService = new UserService(); return userService; } public void test() { System.out.println(\"test\"); }}

对应的UserService类为：

public class CommonService { public UserService createUserService() { return new UserService(); }}

对应的CommonService的类为：

方式二：

如果没有设置Supplier，则检查BeanDefinition中是否设置了factoryMethod，也就是工厂方法，有两种方式可以设置factoryMethod，比如：

5.2 工厂方法创建对象

推断完构造方法后，就会使用构造方法来进行实例化了

额外的，在推断构造方法逻辑中除开会去选择构造方法以及查找入参对象意外，会还判断是否在对应的类中是否存在使用**@Lookup注解**了方法。如果存在则把该方法封装为LookupOverride对象并添加到BeanDefinition中。在实例化时，如果判断出来当前BeanDefinition中没有LookupOverride，那就直接用构造方法反射得到一个实例对象。如果存在LookupOverride对象，也就是类中存在@Lookup注解了的方法，那就会生成一个代理对象。

@Componentpublic class UserService { private OrderService orderService; public void test() { OrderService orderService = createOrderService(); System.out.println(orderService); } @Lookup(\"orderService\") public OrderService createOrderService() { return null; }}

@Lookup注解就是方法注入，使用demo如下：

5.3 推断构造方法

5. 实例化

Spring发现当前BeanDefinition方法设置了工厂方法后，就会区分这两种方式，然后调用工厂方法得到对象。值得注意的是，我们通过@Bean所定义的BeanDefinition，是存在factoryMethod和factoryBean的，也就是和上面的方式二非常类似，@Bean所注解的方法就是factoryMethod，AppConfig对象就是factoryBean。如果@Bean所所注解的方法是static的，那么对应的就是方式一。

Bean对象实例化出来之后，接下来就应该给对象的属性赋值了.在真正给属性赋值之前，Spring又提供了一个扩展点MergedBeanDefinitionPostProcessor.postProcessMergedBeanDefinition()，可以对此时的BeanDefinition进行加工，比如：

在Spring源码中，AutowiredAnnotationBeanPostProcessor就是一个MergedBeanDefinitionPostProcessor，它的postProcessMergedBeanDefinition()中会去查找注入点，并缓存在AutowiredAnnotationBeanPostProcessor对象的一个Map中（injectionMetadataCache）。

6. BeanDefinition的后置处理

在处理完BeanDefinition后，Spring又设计了一个扩展点：InstantiationAwareBeanPostProcessor.postProcessAfterInstantiation()，比如：

7. 实例化后

上述代码就是对userService所实例化出来的对象进行处理。这个扩展点，在Spring源码中基本没有怎么使用

这里的自动注入指的是Spring的自动注入

8. 自动注入

这个步骤中，就会处理@Autowired、@Resource、@Value等注解，也是通过**InstantiationAwareBeanPostProcessor.postProcessProperties()**扩展点来实现的，比如我们甚至可以实现一个自己的自动注入功能，比如：

9. 处理属性

BeanNameAware：回传beanName给bean对象。

BeanClassLoaderAware：回传classLoader给bean对象。

BeanFactoryAware：回传beanFactory给对象。

完成了属性赋值之后，Spring会执行一些回调，包括：

10. 执行Aware

初始化前，也是Spring提供的一个扩展点：BeanPostProcessor.postProcessBeforeInitialization()，比如

利用初始化前，可以对进行了依赖注入的Bean进行处理。

1.InitDestroyAnnotationBeanPostProcessor会在初始化前这个步骤中执行@PostConstruct的方法，

2.ApplicationContextAwareProcessor会在初始化前这个步骤中进行其他Aware的回调：EnvironmentAware：回传环境变量EmbeddedValueResolverAware：回传占位符解析器ResourceLoaderAware：回传资源加载器ApplicationEventPublisherAware：回传事件发布器MessageSourceAware：回传国际化资源ApplicationStartupAware：回传应用其他监听对象，可忽略ApplicationContextAware：回传Spring容器ApplicationContext

在Spring源码中：

11. 初始化前

1.查看当前Bean对象是否实现了InitializingBean接口，如果实现了就调用其afterPropertiesSet()方法

2.执行BeanDefinition中指定的初始化方法

12. 初始化

这是Bean创建生命周期中的最后一个步骤，也是Spring提供的一个扩展点：BeanPostProcessor.postProcessAfterInitialization()，比如：

InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation()实例化MergedBeanDefinitionPostProcessor.postProcessMergedBeanDefinition()InstantiationAwareBeanPostProcessor.postProcessAfterInstantiation()自动注入InstantiationAwareBeanPostProcessor.postProcessProperties()Aware对象BeanPostProcessor.postProcessBeforeInitialization()初始化BeanPostProcessor.postProcessAfterInitialization()

总结BeanPostProcessor

13. 初始化后

可以在这个步骤中，对Bean最终进行处理，Spring中的AOP就是基于初始化后实现的，初始化后返回的对象才是最终的Bean对象。

Bean的生成过程

Bean生命周期源码解析

手动注入

自动注入

Spring中到底有几种依赖注入的方式？

在XML中定义Bean时，就是手动注入，因为是程序员手动给某个属性指定了值。

set方法进行注入

构造方法进行注入

两种方式

获取到set方法中的唯一参数的参数类型，并且根据该类型去容器中获取bean如果找到多个，会报错

Spring在通过byType的自动填充属性时流程

<bean id=\"userService\" class=\"com.luban.service.UserService\" autowire=\"byType\"/>这么写，表示Spring会自动的给userService中所有的属性自动赋值（不需要这个属性上有@Autowired注解，但需要这个属性有对应的set方法）

byType

找到所有set方法所对应的XXX部分的名字根据XXX部分的名字去获取bean

Spring在通过byName的自动填充属性时流程是

byName

那么就可以不写set方法了，当某个bean是通过构造方法来注入时，spring利用构造方法的参数信息从Spring容器中去找bean，找到bean之后作为参数传给构造方法，从而实例化得到一个bean对象，并完成属性赋值（属性赋值的代码得程序员来写）

其实构造方法注入相当于byType+byName，普通的byType是根据set方法中的参数类型去找bean，找到多个会报错，而constructor就是通过构造方法中的参数类型去找bean，如果找到多个会根据参数名确定

Spring通过constructor填充

constructor

表示默认值，我们一直演示的某个bean的autowire，而也可以直接在<beans>标签中设置autowire，如果设置了，那么<bean>标签中设置的autowire如果为default，那么则会用<beans>标签中设置的autowire

default

表示关闭autowire

在XML中，我们可以在定义一个Bean时去指定这个Bean的自动注入的五种模式

name：这个name并不是方法的名字，而是拿方法名字进过处理后的名字span style=\"font-size: inherit;\

PropertyDescriptor中有几个属性

在创建Bean的过程中，在填充属性时，Spring会去解析当前类，把当前类的所有方法都解析出来，Spring会去解析每个方法得到对应的PropertyDescriptor对象

方法参数个数为0个，并且（方法名字以\"get\"开头或者方法名字以\"is\"开头并且方法的返回类型为boolean）

方法参数个数为1个，并且（方法名字以\"set\"开头并且方法返回类型为void）

set方法的定义

get方法的定义

XML的autowire自动注入

@Autowired注解相当于XML中的autowire属性的注解方式的替代。这是在官网上有提到的。

可以发现XML中的自动注入是挺强大的，那么问题来了，为什么我们平时都是用的@Autowired注解呢？而没有用上文说的这种自动注入方式呢？

上文说了@Autowired注解，是byType和byName的结合。

属性上：先根据属性类型去找Bean，如果找到多个再根据属性名确定一个构造方法上：先根据方法参数类型去找Bean，如果找到多个再根据参数名确定一个set方法上：先根据方法参数类型去找Bean，如果找到多个再根据参数名确定一个

@Autowired注解可以写在：

@Autowired注解的自动注入

在创建一个Bean的过程中，Spring会利用AutowiredAnnotationBeanPostProcessor的**postProcessMergedBeanDefinition()**找出注入点并缓存，找注入点的流程为：遍历当前类的所有的属性字段Field查看字段上是否存在@Autowired、@Value、@Inject中的其中任意一个，存在则认为该字段是一个注入点如果字段是static的，则不进行注入获取@Autowired中的required属性的值将字段信息构造成一个AutowiredFieldElement对象，作为一个注入点对象添加到currElements集合中。遍历当前类的所有方法Method判断当前Method是否是桥接方法，如果是找到原方法查看方法上是否存在@Autowired、@Value、@Inject中的其中任意一个，存在则认为该方法是一个注入点如果方法是static的，则不进行注入获取@Autowired中的required属性的值将方法信息构造成一个AutowiredMethodElement对象，作为一个注入点对象添加到currElements集合中。遍历完当前类的字段和方法后，将遍历父类的，直到没有父类。最后将currElements集合封装成一个InjectionMetadata对象，作为当前Bean对于的注入点集合对象，并缓存。

寻找注入点

@Component@Scope(\"prototype\")public class OrderService {}

@Component@Scope(\"prototype\")public class UserService { @Autowired private static OrderService orderService; public void test() { System.out.println(\"test123\"); }}

示例：

static的字段或方法为什么不支持

答案是不是，一旦userService2 创建好了之后，static orderService字段的值就发生了修改了，从而出现bug。

问此时，userService1的orderService值是什么？还是它自己注入的值吗？

看上面代码，UserService和OrderService都是原型Bean，假设Spring支持static字段进行自动注入，那么现在调用两次：UserService userService1 = context.getBean(\"userService\")UserService userService2 = context.getBean(\"userService\")

Spring中当遍历到桥接方法时，得找到原方法

桥接方法

Spring在AutowiredAnnotationBeanPostProcessor的**postProcessProperties()**方法中，会遍历所找到的注入点依次进行注入。

遍历所有的AutowiredFieldElement对象。将对应的字段封装为DependencyDescriptor对象。调用BeanFactory的resolveDependency()方法，传入DependencyDescriptor对象，进行依赖查找，找到当前字段所匹配的Bean对象。将DependencyDescriptor对象和所找到的结果对象beanName封装成一个ShortcutDependencyDescriptor对象作为缓存，比如如果当前Bean是原型Bean，那么下次再来创建该Bean时，就可以直接拿缓存的结果对象beanName去BeanFactory中去那bean对象了，不用再次进行查找了利用反射将结果对象赋值给字段。

字段注入

遍历所有的AutowiredMethodElement对象遍历将对应的方法的参数，将每个参数封装成MethodParameter对象将MethodParameter对象封装为DependencyDescriptor对象调用BeanFactory的resolveDependency()方法，传入DependencyDescriptor对象，进行依赖查找，找到当前方法参数所匹配的Bean对象。将DependencyDescriptor对象和所找到的结果对象beanName封装成一个ShortcutDependencyDescriptor对象作为缓存，比如如果当前Bean是原型Bean，那么下次再来创建该Bean时，就可以直接拿缓存的结果对象beanName去BeanFactory中去那bean对象了，不用再次进行查找了利用反射将找到的所有结果对象传给当前方法，并执行。

Set方法注入

注入点进行注入

依赖注入源码解析

Spring源码解析

spring.xml和AppConfig.class本质上是一样的

目前，我们基本很少直接使用上面这种方式来用Spring，而是使用Spring MVC，或者Spring Boot，但是它们都是基于上面这种方式的，都需要在内部去创建一个ApplicationContext的，只不过：Spring MVC创建的是XmlWebApplicationContext，和ClassPathXmlApplicationContext类似，都是基于XML配置的Spring Boot创建的是AnnotationConfigApplicationContext

Redis安装

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

redis是单线程吗

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。

Redis 单线程为什么还能这么快？

Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

Redis 单线程如何处理那么多的并发客户端连接？

Redis的单线程和高性能

全量遍历键，用来列出所有满足特定正则字符串规则的key，当redis数据量比较大时，性能比较差，要避免使用

keys

渐进式遍历键

SCAN cursor [MATCH pattern] [COUNT count] scan 参数提供了三个参数，第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。注意：但是scan并非完美无瑕，如果在scan的过程中如果有键的变化（增加、删除、修改），那么遍历效果可能会碰到如下问题：新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键，这些是我们在开发时需要考虑的。

scan

查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是: Server 服务器运行的环境参数 Clients 客户端相关信息 Memory 服务器运行内存统计数据 Persistence 持久化信息 Stats 通用统计数据 Replication 主从复制相关信息 CPU CPU 使用情况 Cluster 集群信息 KeySpace 键值对统计数量信息

Info

其他高级命令

核心数据结构与高性能原理

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。你可以对 Redis 进行设置，让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时，自动保存一次数据集。比如说，以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时，自动保存一次数据集：# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可

还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

诠释

save与bgsave对比

配置自动生成rdb文件后台使用的是bgsave方式。

RDB快照（snapshot）

快照功能并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)

# appendonly yes

你可以通过修改配置文件来打开 AOF 功能

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。

从现在开始，每当 Redis 执行一个改变数据集的命令时（比如 SET），这个命令就会被追加到 AOF 文件的末尾。这样的话，当 Redis 重新启动时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件

# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大# auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写

两个配置可以控制AOF自动重写频率

当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响

AOF重写

AOF（append-only file）

生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。

RDB 和 AOF ，我应该用哪一个？

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

# aof-use-rdb-preamble yes

通过如下配置可以开启混合持久化(必须先开启aof)：

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。

混合持久化AOF文件结构如下

Redis 4.0 混合持久化

写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份每次copy备份的时候，都把太旧的备份给删了每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏

Redis数据备份策略：

Redis持久化

如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC命令给master请求复制数据。master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。

主从复制(全量复制)流程图：

当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

主从复制(部分复制，断点续传)流程图

数据部分复制

如果有很多从节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以做如下架构，让部分从节点与从节点(与主节点同步)同步数据

主从工作原理

Redis主从架构

sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。

哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

哨兵高可用架构

客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低多条命令执行的网络传输开销，管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续执行。

管道（Pipeline）

Redis在2.6推出了脚本功能，允许开发者使用Lua语言编写脚本传到Redis中执行。

1、减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。这点跟管道类似。2、原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。3、替代redis的事务功能：redis自带的事务功能很鸡肋，而redis的lua脚本几乎实现了常规的事务功能，官方推荐如果要使用redis的事务功能可以用redis lua替代。

使用脚本的好处如下:

注意，不要在Lua脚本中出现死循环和耗时的运算，否则redis会阻塞，将不接受其他的命令，所以使用时要注意不能出现死循环、耗时的运算。redis是单进程、单线程执行脚本。管道不会阻塞redis。

Lua脚本

redis管道与调用lua脚本

spring 封装了 RedisTemplate 对象来进行对redis的各种操作，它支持所有的 redis 原生的 api

StringRedisTemplate继承自RedisTemplate，也一样拥有上面这些操作。

StringRedisTemplate默认采用的是String的序列化策略，保存的key和value都是采用此策略序列化保存的。

RedisTemplate默认采用的是JDK的序列化策略，保存的key和value都是采用此策略序列化保存的。

Redis客户端命令对应的RedisTemplate中的方法列表

StringRedisTemplate与RedisTemplate详解

持久化、主从与哨兵架构

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master

哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况

而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发

单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率

哨兵模式

redis集群是一个由多个主从节点群组成的分布式服务集群，它具有复制、高可用和分片特性。

Redis集群不需要sentinel哨兵·也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。

redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单

高可用集群模式

集群方案比较

redis集群需要至少三个master节点

高可用集群搭建

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。HASH_SLOT = CRC16(key) mod 16384

槽位定位算法

当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表。

跳转重定位

redis cluster节点间采取gossip协议进行通信

优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。很多中间件都会借助zookeeper集中式存储元数据

集中式

meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信；ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)； pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新； fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

gossip协议包含多种消息，包括ping，pong，meet，fail等等。

gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后

每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping消息之后返回pong消息

gossip通信的10000端口

gossip

维护集群的元数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip

真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。为解决这种问题，Redis Cluster 提供了一种选项cluster-node-timeout，表示当某个节点持续 timeout 的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换 (数据的重新复制)。

网络抖动

Redis集群节点间的通信机制

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程，其过程如下：1.slave发现自己的master变为FAIL2.将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)6.slave广播Pong消息通知其他集群节点。

从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票•延迟计算公式： DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）。

Redis集群选举原理分析

redis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。

规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群leader选举机制)：min-replicas-to-write 1 //写数据成功最少同步的slave数量，这个数量可以模仿大于半数机制配置，比如集群总共三个节点可以配置1，加上leader就是2，超过了半数

注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。

集群脑裂数据丢失问题

当redis.conf的配置cluster-require-full-coverage为no时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为yes则集群不可用。

集群是否完整才能对外提供服务

因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。

奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

对于类似mset，mget这样的多个key的原生批量操作命令，redis集群只支持所有key落在同一slot的情况，如果有多个key一定要用mset命令在redis集群上操作，则可以在key的前面加上{XX}，这样参数数据分片hash计算的只会是大括号里的值，这样能确保不同的key能落到同一slot里去，示例如下：mset {user1}:1:name zhuge {user1}:1:age 18假设name和age计算的hash slot值不一样，但是这条命令在集群下执行，redis只会用大括号里的 user1 做hash slot计算，所以算出来的slot值肯定相同，最后都能落在同一slot。

Redis集群对批量操作命令的支持

Redis集群原理分析

高可用集群

string类型的incr和decr命令的作用是将key中储存的数字值加一/减一，这两个操作具有原子性，总能安全地进行加减操作，因此可以用string类型进行计数，如微博的评论数、点赞数、分享数，作品的收藏数，京东商品的销售量、评价数等。

计数器

分布式锁

利用JSON强大的兼容性、可读性和易用性，将对象转换为JSON字符串，再存储在string类型中，是个不错的选择，如用户信息、商品信息等。

存储对象

String

hash类型是一个string类型的field和value的映射表，每个 hash 可以存储 232 - 1 键值对（40多亿）

以用户id为key，商品id为field，商品数量为value，恰好构成了购物车的3个要素

购物车

hash

list类型是简单的字符串列表，按照插入顺序排序。每个列表最多可以存储 232 - 1 个元素（40多亿）

list类型的lpop和rpush（或者反过来，lpush和rpop）能实现队列的功能，故而可以用Redis的list类型实现简单的点对点的消息队列。不过我不推荐在实战中这么使用，因为现在已经有Kafka、NSQ、RabbitMQ等成熟的消息队列了，它们的功能已经很完善了，除非是为了更深入地理解消息队列，不然我觉得没必要去重复造轮子。

消息队列

list类型的lrange命令可以分页查看队列中的数据。可将每隔一段时间计算一次的排行榜存储在list类型中，如京东每日的手机销量排行、学校每次月考学生的成绩排名、斗鱼年终盛典主播排名等，下图是酷狗音乐“K歌擂台赛”的昨日打擂金曲排行榜，每日计算一次，存储在list类型中，接口访问时，通过page和size分页获取打擂金曲。（打个小广告，酷狗音乐“K歌擂台赛”每天都能产生一批优质翻唱作品，对普通人优质歌声有兴趣的朋友不妨来听听）。但是，并不是所有的排行榜都能用list类型实现，只有定时计算的排行榜才适合使用list类型存储，与定时计算的排行榜相对应的是实时计算的排行榜，list类型不能支持实时计算的排行榜，之后在介绍有序集合sorted set的应用场景时会详细介绍实时计算的排行榜的实现。

排行榜

list类型的lpush命令和lrange命令能实现最新列表的功能，每次通过lpush命令往列表里插入新的元素，然后通过lrange命令读取最新的元素列表，如朋友圈的点赞列表、评论列表。但是，并不是所有的最新列表都能用list类型实现，因为对于频繁更新的列表，list类型的分页可能导致列表元素重复或漏掉，举个例子，当前列表里由表头到表尾依次有（E，D，C，B，A）五个元素，每页获取3个元素，用户第一次获取到（E，D，C）三个元素，然后表头新增了一个元素F，列表变成了（F，E，D，C，B，A），此时用户取第二页拿到（C，B，A），元素C重复了。只有不需要分页（比如每次都只取列表的前5个元素）或者更新频率低（比如每天凌晨更新一次）的列表才适合用list类型实现。对于需要分页并且会频繁更新的列表，需用使用有序集合sorted set类型实现。另外，需要通过时间范围查找的最新列表，list类型也实现不了，也需要通过有序集合sorted set类型实现，如以成交时间范围作为条件来查询的订单列表。之后在介绍有序集合sorted set类型的应用场景时会详细介绍sorted set类型如何实现最新列表。那么问题来了，对于排行榜和最新列表两种应用场景，list类型能做到的sorted set类型都能做到，list类型做不到的sorted set类型也能做到，那为什么还要使用list类型去实现排行榜或最新列表呢，直接用sorted set类型不是更好吗？原因是sorted set类型占用的内存容量是list类型的数倍之多（之后会在容量章节详细介绍），对于列表数量不多的情况，可以用sorted set类型来实现，比如上文中举例的打擂金曲排行榜，每天全国只有一份，两种数据类型的内存容量差距可以忽略不计，但是如果要实现某首歌曲的翻唱作品地区排行榜，数百万的歌曲，300多个地区，会产生数量庞大的榜单，或者数量更加庞大的朋友圈点赞列表，就需要慎重地考虑容量的问题了。