G1

G1也是属于并发分代收集器。

堆区域：

• 年轻代区域
• Eden区域 - 新分配的对象 - TLAB
• Survivor区域 - 年轻代GC存活后但不需要晋升的对象 - RSet
• 老年代区域
• 晋升到老年代的对象
• 直接分配到老年代的大对象，占用多个区域的对象，通常是大于Region的一半

G1的Collector可以分为两个大部分：

• 全局并发标记 (global concurrent marking)
• 拷贝存活对象(evacuation)

其分代收集模式又有，区别在于选定的CSet：

• Young GC
• Mixed GC
• Full GC 前两者都是标记-复制作为回收算法

其中的几个关键技术有：

• 停顿预测模型
• TLAB
• RSet
• SATB & SATB MarkQueue & Write barrier
• Safe Point

全局并发标记

全局并发标记是基于SATB形式的并发标记，具体来说，其分为下面几个阶段：

1. 初始标记(Initial Marking): STW 扫描GC roots集合，标记所有从根集合可直接到达的对象并将它们的字段压入扫描栈 (marking stack)中等待后续扫描。G1使用外部的bitmap来记录mark信息，而不是用对象头的mark word里的mark bit。在分代式G1模式中，初始标记阶段借用Young GC的暂停，即没有额外、单独的STW。并且在Mixed GC中，还会根据Youn GC扫描后的Survivor的RSet作为根更新待扫描的GC Roots，将指向的对象同样压入扫描栈。
2. 并发标记(Concurrent marking): Concurrent 不断从扫描栈取出引用递归扫描整个堆里的对象图。每扫描到一个对象就会对其标记，并将其字段压入扫描栈。重复扫描过程直到扫描栈清空。过程中还会扫描SATB write barrier所记录下的引用。
3. 最终标记（final marking，在实现中也叫remarking）: STW 在完成并发标记后，每个Java线程还会有一些剩下的SATB write barrier记录的引用尚未处理。这个阶段就负责把剩下的引用处理完。同时这个阶段也进行弱引用处理（reference processing）。注意这个暂停与CMS的remark有一个本质上的区别，那就是这个暂停只需要扫描SATB buffer，而CMS的remark需要重新扫描mod-union table里的dirty card外加整个根集合，而此时整个young gen（不管对象死活）都会被当作根集合的一部分，因而CMS remark有可能会非常慢
4. 清理（cleanup）: STW 清点和重置标记状态。这个阶段有点像mark-sweep中的sweep阶段，不过不是在堆上sweep实际对象，而是在marking bitmap里统计每个region被标记为活的对象有多少。这个阶段如果发现完全没有活对象的region就会将其整体回收到可分配region列表中。

拷贝存活对象

Evacuation阶段是全暂停的。它负责把一部分region里的活对象拷贝到空region里去，然后回收原本的region的空间。
Evacuation阶段可以自由选择任意多个region来独立收集构成收集集合（collection set，简称CSet），靠per-region remembered set（简称RSet）实现。这是regional garbage collector的特征。
在选定CSet后，evacuation其实就跟ParallelScavenge的young GC的算法类似，采用并行copying（或者叫scavenging）算法把CSet里每个region里的活对象拷贝到新的region里，整个过程完全暂停。从这个意义上说，G1的evacuation跟传统的mark-compact算法的compaction完全不同：前者会自己从根集合遍历对象图来判定对象的生死，不需要依赖global concurrent marking的结果，有就用，没有拉倒；而后者则依赖于之前的mark阶段对对象生死的判定。

注意，该部分也与初始标记阶段相同，复用了Young GC的代码。

TLAB

TLAB的核心思想在于优化各个线程从堆内存中新建对象的过程，通过估算每轮GC内每个线程使用的内存大小，提前分配好内存给线程，提高分配效率，避免由于撞针分配及CAS操作带来的性能损失，称之为TLAB(Thread Local Allocate Buffer)。注意，TLAB是线程私有的。

JVM 对象堆内存分配流程简述

具体来说，当分配一个对象堆内存空间时(new Object())，CollectedHeap首先检查是否启用了TLAB，如果启用了，则会尝试TLAB分配 - 如果当前线程的 TLAB 大小足够，那么从线程当前的 TLAB 中分配；如果不够，但是当前 TLAB 剩余空间小于最大浪费空间限制，则从堆上（一般是 Eden 区） 重新申请一个新的 TLAB 进行分配。否则，直接在 TLAB 外进行分配。TLAB 外的分配策略，不同的 GC 算法不同。例如G1：

1. 对于超过1/2 region大小的对象，直接分配在Humongous区域
2. 根据当前用户线程的状态进行region下标的分配

G1 与 TLAB 的关联

new新对象 -> TLAB分配 -> TLAB不可容纳 -> TLAB外进行分配 -> 从Eden区获取新的TLAB -> Eden区不够 -> 判断回收时间，是触发Young GC还是将空闲分区加入Eden区再次分配

GC回收 -> 将Eden Region变为free region -> 更改相应TLAB参数，重新分配 -> 循环进行 new 新对象

TLAB的生命周期

TLAB 是线程私有的，线程初始化的时候，会创建并初始化 TLAB。同时，在 GC 扫描对象发生之后，线程第一次尝试分配对象的时候，也会创建并初始化 TLAB，即再分配。 TLAB 生命周期停止（TLAB 声明周期停止不代表内存被回收，只是代表这个 TLAB 不再被这个线程私有管理，即可以通过EMA计算大小后再分配）在：

• 当前 TLAB 不够分配，并且剩余空间小于最大浪费空间限制，那么这个 TLAB 会被退回 Eden，重新申请一个新的
• 发生 GC 的时候，TLAB 被回收。

==最大浪费空间可以看作是可容忍的internal fragmentation大小，即小于这个数值的内存碎片，是可以被容忍的==

直接从堆上分配

直接从堆上分配是最慢的分配方式。一种情况就是，如果当前 TLAB 剩余空间大于当前最大浪费空间限制，直接在堆上分配。并且，还会增加当前最大浪费空间限制，每次有这样的分配就会增加 TLABWasteIncrement 的大小，这样在一定次数的直接堆上分配之后，当前最大浪费空间限制一直增大会导致当前 TLAB 剩余空间小于当前最大浪费空间限制，从而申请新的 TLAB 进行分配。

返还TLAB给Eden区时，填充Dummy Object的必要性

当GC扫描时，此时的TLAB要返还给Eden区，即堆区域。

具体而言，填充Dummy Object实际发生在GC之前，以G1举例，此时要先确保堆内存是可解析的，即将所有线程的TLAB填充Dummy Object后，返还给堆，核心在于更快速的扫描堆上的对象，以及采样一些东西利于接下来TLAB大小的计算。

考虑不填充dummy object，此时堆内存中对于已经存在的对象不会存在影响，但是对于未使用的部分，GC线程并不知道其中是否会有对象，就会逐字节的扫描，影响效率。

填充Dummy Object是以对象头中的Mark word的一个int[]数组决定的，因此不能超过int[]数组的最大大小

TLAB的再分配

通过EMA采样(Exponential Moving Averange, 指数平均数)，得到新的TLAB大小期望值，该期望值与Eden区的总大小有关，在[#G1 与 TLAB 的关联](#G1 与 TLAB 的关联 “wikilink”)中，概述了这个Eden区的大小的变化过程

具体来说，EMA算法的核心在于最小权重，即最小权重越大，变化得越快，受历史数据影响越小。

每个线程 TLAB 初始大小 = Eden区大小 / (线程单个 GC 轮次内最多从 Eden 申请多少次 TLAB * 当前 GC 分配线程个数 EMA)

GC 后，重新计算 TLAB 大小 = Eden区大小 / (线程单个 GC 轮次内最多从 Eden 申请多少次 TLAB * 当前 GC 分配线程个数 EMA)

RSet - Remember Set

G1将堆内存划分为大小相等的region，新创建的对象都是放在新生代的Eden区。为了加速Initial Marking阶段中的GC Roots根扫描阶段，引入了RSet这一概念，具体来说，RSet存储了Region间的引用关系，主要是记录了如下两种：

• Old Region -> Young Region
• Old Region -> Old Region

内部数据结构

Card Table 卡表

卡表就是将Region进一步划分为若干个物理连续的512Byte的Card Page，这样每个Region就都有一个Card Table来映射，并且整个堆空间也有一个Global Card Table

Sparse PRT 稀疏哈希表

此方法内存开销较大，进一步缩减，得到细粒度PRT

细粒度 PRT

通过一个bit位来表示卡表

粗粒度位图

再度优化细粒度PRT的内存，每个bit位表示一个Region

Refine线程

Refine线程的核心功能在于：

• 处理新生代分区的抽样 - 更新Young Heap Region的数目
• 使G1满足GC的预测停顿时间-XX:MaxGCPauseMillis
• 管理RSet
• 更新RSet
• 将G1中更新的引用关系从DCQS - Dirty Card Queue Set 中更新到RSet中
• 每个线程都有一个私有的DCQ，而DCQS是全局静态变量
• 并发、异步处理

SATB & SATB MarkQueue & Write barrier

SATB，SnapShot-At-The-Beginning，是维护并发GC的正确性的一个手段，G1 GC并发理论基础就是SATB。

抽象来说，G1 GC认为在一次GC开始的时候是活的对象就被认为是活的（GC Roots搜索），此时的对象图形成一个逻辑快照（SnapShot），然后在GC过程中新分配的对象都当作是活的，其他不可到达的对象就是死的。通过每个Region记录着的Top-At-Mark-Start，TAMS，指针，分别为prevTAMS和nextTAMS，在TAMS以上的对象就是新分配的。但是在并发GC中，Collector和Mutator线程都在进行，如果collector并发mark的过程中mutator覆盖了某些引用字段的值而collector还没mark到那里，那collector就得不到完整的snapshot了，因此，引入了SATB Write Barrier来解决这个问题。

SATB Write Barrier

Write barrier是对"对引用类型字段赋值"这个动作的环切，也就是说赋值的前后都在barrier覆盖的范畴内。在赋值前的部分的write barrier叫做pre-write barrier，在赋值后的则叫做post-write barrier。

前面提到SATB要维持"在GC开始时活的对象"的状态这个逻辑snapshot。除了从root出发把整个对象图mark下来之外，其实只需要用pre-write barrier把每次引用关系变化时旧的引用值记下来就好了。这样，等concurrent marker到达某个对象时，这个对象的所有引用类型字段的变化全都有记录在案，就不会漏掉任何在snapshot里活的对象。当然，很可能有对象在snapshot中是活的，但随着并发GC的进行它可能本来已经死了，但SATB还是会让它活过这次GC。

SATB Mark Queue

为了尽量减少write barrier对mutator性能的影响，G1将一部分原本要在barrier里做的事情挪到别的线程上并发执行。
实现这种分离的方式就是通过logging形式的write barrier：mutator只在barrier里把要做的事情的信息记（log）到一个队列里，然后另外的线程从队列里取出信息批量完成剩余的动作。

以SATB write barrier为例，每个Java线程有一个独立的、定长的SATBMarkQueue，mutator在barrier里只把old_value压入该队列中。一个队列满了之后，它就会被加到全局的SATB队列集合SATBMarkQueueSet里等待处理，然后给对应的Java线程换一个新的、干净的队列继续执行下去。

并发标记（concurrent marker）会定期检查全局SATB队列集合的大小。当全局集合中队列数量超过一定阈值后，concurrent marker就会处理集合里的所有队列：把队列里记录的每个oop都标记上，并将其引用字段压到标记栈（marking stack）上等后面做进一步标记。

这个队列与DCQ的区别在于，前者是Refine线程处理，用于在堆的日常运维中追踪被修改的内存区域，优化垃圾收集的效率，SATB mark queue是mutator线程协助处理，用于记录并发标记阶段开始时对象的引用状态，确保标记的完整性和一致性。并且两者处理的数据类型和GC过程中的角色不一样：SATB Mark Queue 处理对象引用，特别是在堆修改前的状态；Dirty Card Queue 处理的是堆内存中的区域（card），这些区域在被修改时被标记为脏；SATB Mark Queue 在并发标记阶段发挥作用，帮助实现堆状态的一致性快照；Dirty Card Queue 在整个垃圾收集过程中都可能被使用，用于标记和处理那些自上次垃圾收集以来发生变化的堆区域。

选取CSet的子模式

Young GC

选定所有young gen里的region。通过控制young gen的region个数来控制young GC的开销（Refine线程所做的事）

• 触发时机：

  • 新的对象创建会放入Eden区
  • Eden区满、G1会根据停顿预测模型-计算当前Eden区GC大概耗时多久
  • 如果回收时间远 < -XX:MaxGCPauseMills,则分配空闲分区加入Eden 区存放
  • 如果回收时间接近-XX:MaxGCPauseMills，则触发一次Young GC

• 年轻代初始占总堆5%，随着空闲分区加入而增加，最多不超过60%

• Young GC 会回收all新生代分区 - Eden区和Survivor 区

• Young GC 会STW(stop the world),暂停所有用户线程

• GC后重新调整新生代Region数目，每次GC回收Region数目不固定

• 回收过程：

  • 扫描根 - GC Roots
  • 更新RSet - Refine线程
  • 处理RSet - 扫描RSet
  • 复制对象 - Evacuation
  • 处理引用 - 重构RSet及卡表

Mixed GC

选定所有young gen里的region，外加根据global concurrent marking统计得出收集收益高的若干old gen region。在用户指定的开销目标范围内尽可能选择收益高的old gen region。

• 回收过程
  • 复用 Young GC 的 Initial Marking，并根据Survivor区中的RSet再次根扫描，压入扫描栈
  • 并发标记阶段 - 从扫描栈与SATB MarkQueue中递归进行标记
  • 再标记阶段 - STW，完全处理SATB MarkQueue
  • 清理阶段 - 确认回收对象
  • 复制对象阶段 - 复用 Young GC 中的复制代码 ## 分代式G1

分代式G1的正常工作流程就是在young GC与mixed GC之间视情况切换，背后定期做做全局并发标记。Initial marking默认搭在young GC上执行；当全局并发标记正在工作时，G1不会选择做mixed GC，反之如果有mixed GC正在进行中G1也不会启动initial marking。 在正常工作流程中没有full GC的概念，old gen的收集全靠mixed GC来完成。

如果mixed GC实在无法跟上程序分配内存的速度，导致old gen填满无法继续进行mixed GC，就会切换到G1之外的serial old GC来收集整个GC heap（注意，包括young、old、perm）。这才是真正的full GC。Full GC之所以叫full就是要收集整个堆，只选择old gen的部分region算不上full GC。进入这种状态的G1就跟-XX:+UseSerialGC的full GC一样（背后的核心代码是两者共用的）。
顺带一提，G1 GC的System.gc()默认还是full GC，也就是serial old GC。只有加上 -XX:+ExplicitGCInvokesConcurrent 时G1才会用自身的并发GC来执行System.gc()——此时System.gc()的作用是强行启动一次global concurrent marking；一般情况下暂停中只会做initial marking然后就返回了，接下来的concurrent marking还是照常并发执行。

Safe Point

正如 Safe Point 名称的寓意一样，Safe Point 是一个线程可以安全停留在这里的代码点。当我们需要进行 GC 操作的时候，JVM 可以让所有线程在 Safe Point 处停留下来，等到所有线程都停在 Safe Point 处时，就可以进行内存引用分析，从而确定哪些对象是存活的、哪些对象是不存活的。

为什么让大家更加场景化地理解 Safe Point 这个概念，可以设想如下场景：

1. 当需要 GC 时，需要知道哪些对象还被使用，或者已经不被使用可以回收了，这样就需要每个线程的对象使用情况。
2. 对于偏向锁（Biased Lock），在高并发时想要解除偏置，需要线程状态还有获取锁的线程的精确信息。
3. 对方法进行即时编译优化（OSR 栈上替换），或者反优化（bailout 栈上反优化），这需要线程究竟运行到方法的哪里的信息。

对于上面这些操作，都需要知道现场的各种信息，例如寄存器有什么内容，堆使用情况等等。在做这些操作的时候，线程需要暂停，等到这些操作完成才行，否则会有并发问题，这就需要 Safe Point 的存在。

因此，我们可以将 Safe Point 理解成代码执行过程中的一些特殊位置，当线程执行到这个位置时，线程可以暂停。 Safe Point 处保存了其他位置没有的一些当前线程信息，可以提供给其他线程读取，这些信息包括：线程上下文信息，对象的内部指针等。

而 Stop the World 就是所有线程同时进入 Safe Point 并停留在那里，等待 JVM 进行内存分析扫描，接着进行内存垃圾回收的时间。

为啥需要 Safe Point

前面我们说到，Safe Point 其实就是一个代码的特殊位置，在这个位置时线程可以暂停下来。而当我们进行 GC 的时候，所有线程都要进入到 Safe Point 处，才可以进行内存的分析及垃圾回收。根据这个过程，其实我们可以看到：Safe Point 其实就是栅栏的作用，让所有线程停下来，否则如果所有线程都在运行的话，JVM 无法进行对象引用的分析，那么也无法进行垃圾回收了。

此外，另一个重要的 Java 线程特性 —— interrupted 也是根据 Safe Point 实现的。当我们在代码里写入 Thread.interrupt() 时，只有线程运行到 Safe Point 处时才知道是否发生了 interrupted。因此，Safe Point 也承担了存储线程通信的功能。

GC 日志打印

• 打印基本GC信息
  • -XX:+PrintGCDetails -XX:PrintGCDateStamps
• 打印对象分布 - 根据Age
  • -XX:+PrintTenuringDistribution
• GC后打印堆数据
  • -XX:+PrintHeapAtGC
• 打印STW时间
  • -XX:+PrintGCApplicationStoppedTime
• 打印 Safe Point 信息
  • -XX:+PringSafepointStatistics -XX:PrintSafepointStatisticsCount=1
• 打印 Reference 处理信息
  • -XX:+PrintReferenceGC
• 日志分割
  • -Xloggc:/path/tp/gc.log - GC日志输出的文件路径
  • -XX:UseGCLogFileRotation - 开启日志文件分割
• 时间戳命名文件
  • -XX:PrintGCDetails -XX:+PrintGCDataStamps -Xloggc:/path/to/gc-%t.log

• https://www.cnblogs.com/chanshuyi/p/head-first-of-jvm-safe-point.html
• https://segmentfault.com/a/1190000039411521
• https://juejin.cn/post/6949885566536138783?searchId=202406240957236755114659D501068D8D
• https://blog.csdn.net/m0_63437643/article/details/122601042
• https://tech.meituan.com/2016/09/23/g1.html
• https://hllvm-group.iteye.com/group/topic/44381#post-272188
• https://www.zhihu.com/question/53613423/answer/135743258
• https://blog.csdn.net/oJieSi/article/details/134758659

走进JVM

编译JDK8

使用 WSL2 + Docker进行编译测试

• 配置Docker内的ssh，开放端口
• 更新源时忽略ssl验证[options]
• 修改三个报错信息
  • 描述符
  • 时间
  • 已不支持的头文件

JVM启动流程

JavaMain

该函数是Main入口点，位于jdk/src/share/bin/java.c

JLI_Launch

LoadJavaVM()、JVMInit()、ContinueInNewThread0()都由不同的系统实现，只定义了头文件(动态加载jvm.so这个共享库，并把jvm.so中的相关函数导出并且初始化)

JNI调用本地方法

javac -h out/production/jni_test src/com/test/Main.java

.dylib/.dll 动态链接库

static{ System.load(.dll) }

JVM内存管理

内存区域划分

程序计数器（线程独立）

与8086CPU中PC寄存器类似，指向当前线程所执行字节码的行号

虚拟机栈（线程独立）

当每个方法被执行的时候，JVM都会同步创建一个栈帧，其中包含当前方法的一些信息，比如局部变量表，操作数栈，动态链接，方法出口等。

局部变量表

方法中的局部变量

操作数栈

执行字节码时使用到的栈结构

运行时常量池

在当前方法中如果需要调用其他方法的时候，能够从运行时常量池中找到对应的符号引用，然后在==类加载的解析阶段==替换为直接引用，调用对应的方法，即为动态链接。

在JDK8之后，运行时常量池存储于metaSpace中，字符串常量池除外，依旧在Heap中。

本地方法栈

与虚拟机栈类似，但是供JNI使用

堆

是整个Java应用程序共享的区域，此区域的职责就是存放和管理对象和数组，是垃圾回收机制的主要作用区域

方法区 (JDK8 - Metaspace)

该区域也是整个Java应用程序共享的区域，它存储所有的类信息、常量、静态变量、动态编译缓存等数据，大体分为，类信息表与运行时常量池，两个部分。

类信息表中存放的是当前应用程序加载的所有类信息，包括类的版本、字段、方法、接口等信息，同时会将编译时生成的常量池数据全部存放到运行时常量池中。当然，常量也并不是只能从类信息中获取，在程序运行时，也有可能会有新的常量进入到常量池。

• String -> 常量池
• .intern() Heap与常量池的关系
• Integer与int在jvm的存储差异
  • 前者存储在Heap中，是一个对象，后者直接存储在StackFrame中，是一个实际的数值

申请堆外内存

Unsafe.allocateMemory()

垃圾回收机制

对象存活判定算法

引用计数法

存在互相引用问题

可达性分析算法

可以被选为GC Roots的条件如下：

• 在虚拟机栈的栈帧中的局部变量表中的指向GC堆里的对象的引用；当前所有正在被调用的方法的引用类型的参数/局部变量/临时值
• 虚拟机内部需要用到的对象，例如类加载器的引用，等
• JNI handles
• 所有当前被加载的Java类
• 使用类的静态成员变量对对象的引用
• 常量池中对对象的引用(.intern())
• 被添加了锁的对象的引用(synchronized)

是对象的引用作为gc root 而不是被引用的对象

[!NOTE] Title 在Java虚拟机（JVM）的垃圾回收（GC）过程中，当考虑局部变量表中的元素作为GC Roots时，是对象的引用而非被引用的对象本身，作为GC Roots。这个区分是重要的，因为它影响了垃圾回收器如何确定对象的可达性。

解释 局部变量表中的引用： 在每个活动线程的栈帧中，局部变量表存储着各种类型的数据，包括各种基本数据类型的值和对象引用。 对于对象类型，局部变量表存储的是指向堆中对象的引用（也就是对象的内存地址），而不是对象本身。 这些引用作为起点（GC Roots）被用于在垃圾回收过程中的可达性分析。 为什么是引用而不是对象： GC Roots的概念是用来标识垃圾收集算法的起点。这些起点本身必须是明确的、易于识别的，且在栈上直接可访问的元素。 局部变量表中的引用直接存在于栈帧中，JVM可以快速访问这些引用，并使用它们来查找实际的对象实例。 如果对象实例本身位于堆中，就不能直接作为GC Roots。堆中的对象的存活与否是需要通过引用的可达性来判断的。

最终判定

Object#finalize()方法

垃圾回收算法

分代收集机制

JVM将堆内存区域划分为新生代，老年代，永久代（JDK8后由metaSpace代替）

通过设置JVM不同的垃圾收集器，提供不同的具体实现

Minor GC

次要垃圾回收，主要进行新生代区域的垃圾收集。触发条件：新生代的Eden区容量已满时。

Major GC

主要垃圾回收，主要进行老年代的垃圾收集。

FullGC

完全垃圾回收，对整个Java堆内存和方法区进行垃圾回收。 触发条件：

• 每次晋升到老年代的对象平均大小大于老年代剩余空间
• Minor GC后存活的对象超过了老年代剩余空间
• 永久代内存不足（JDK8之前）
• 手动调用System.gc()方法

空间分配担保

若在一次GC后，新生代Eden区存在的大量对象，超出了Survivor区的容量，这时候就需要使用该机制，将Survivor区无法容纳的对象直接送到老年代，而老年代也存在无法容纳的情况，这时候就会调用Full GC进行大规模垃圾回收，尝试腾出空间，否则直接抛出OOM错误。

标记-清除算法

标记-复制算法

标记-整理算法

垃圾收集器实现

Serial收集器

新生代收集算法采用标记-复制，老年代采用标记-整理

ParNew收集器

相当于Serial收集器的多线程版本，除了GC线程支持多线程以外没有大区别

Parallel Scavenge/Parallel Old收集器

新生代收集算法采用标记-复制，老年代采用标记-整理，ParNew收集器不同的是，它会自动衡量一个吞吐量，并根据吞吐量来决定每次垃圾回收的时间，这种自适应机制，能够很好地权衡当前机器的性能，根据性能选择最优方案。

CMS收集器

该收集器可以并发执行，主要采用标记-清除算法 CMS垃圾回收分为4个阶段：

• 初始标记（需要暂停用户线程）：这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象，速度比较快，不用担心会停顿太长时间。
• 并发标记：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
• 重新标记（需要暂停用户线程）：由于并发标记阶段可能某些用户线程会导致标记产生变得，因此这里需要再次暂停所有线程进行并行标记，这个时间会比初始标记时间长一丢丢。
• 并发清除：最后就可以直接将所有标记好的无用对象进行删除，因为这些对象程序中也用不到了，所以可以与用户线程并发运行。

虽然它的优点非常之大，但是缺点也是显而易见的，标记清除算法会产生大量的内存碎片，导致可用连续空间逐渐变少，长期这样下来，会有更高的概率触发Full GC，并且在与用户线程并发执行的情况下，也会占用一部分的系统资源，导致用户线程的运行速度一定程度上减慢。

Garbage First（G1）收集器

G1收集器绕过了Minor GC、Major GC、Full GC，将整个Java堆划分为2048个大小相同的独立Region块，每一个Region都可以根据需要，自由决定扮演哪个角色（Eden、Survivor和老年代），收集器会根据对应的角色采用不同的回收策略。此外，G1收集器还存在一个Humongous区域，它专门用于存放大对象（一般认为大小超过了Region容量一半的对象为大对象）这样，新生代、老年代在物理上，不再是一个连续的内存区域，而是到处分布的。 G1的回收过程与CMS大体类似：

• 初始标记（暂停用户线程）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
• 并发标记：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。
• 最终标记（暂停用户线程）：对用户线程做一个短暂的暂停，用于处理并发标记阶段漏标的那部分对象。
• 筛选回收：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多个收集器线程并行完成的。

元空间

其他引用类型

类与类加载

类文件结构

类文件信息

• 存储顺序
  • 魔数
  • 版本号
  • 常量池 - 字面量和符号引用 具体内容可翻看书籍与笔记，注意主要存储信息都是以字节为单位

字节码指令

ASM字节码编程

类加载机制

类加载过程

要加载一个类，一定是出于某种目的的，比如我们要运行我们的Java程序，那么就必须要加载主类才能运行主类中的主方法，又或是我们需要加载数据库驱动，那么可以通过反射来将对应的数据库驱动类进行加载。

所以，一般在这些情况下，如果类没有被加载，那么会被自动加载：

• 使用new关键字创建对象时
• 使用某个类的静态成员（包括方法和字段）的时候（当然，final类型的静态字段有可能在编译的时候被放到了当前类的常量池中，这种情况下是不会触发自动加载的）
• 使用反射对类信息进行获取的时候（之前的数据库驱动就是这样的）
• 加载一个类的子类时
• 加载接口的实现类，且接口带有default的方法默认实现时 加载过程详见itbaima笔记

一些需要注意的点：

• static final string类型的字符串会被JVM优化到字符串常量池中，不会加载对应的类
• 数组类型在创建时不会导致类加载，但是数组中的对象创建时，就会导致类加载
• class文件，metaspace，heap中类对象，gc roots，不同的类加载器
• 类字面量，String a与String.class之间的差异
• 静态方法是在自动生成的<clinit>方法中执行

类加载器

不同的Class<?>对象的GC ROOTs可以为不同的类加载器，于是同一.class文件加载的类也可以不属于同一个metaSpace中的类信息，具体见JavaSE中的反射与双亲委派机制。

• Object#getClass()也和BootstrapClassLoader一样是JNI方法
• 区分Object.class和Object().getClass()方法的区别，前者是类字面量，后者是方法，但都是获取Heap中的对应的Class<?>对象，其指向metaSpace区的类信息

JVM - OOM错误

Bean的生命周期为：BeanFactory初始化 - Bean注册 - 实例化 - 属性注入 - 初始化 - 后处理

Bean的注册

1. 扫描：Spring通过配置（XML配置或Java配置）或自动扫描（@ComponentScan）来发现应用中定义的Bean。对于自动扫描，Spring会在指定的包路径下查找标注了@Component、@Service、@Repository、@Controller等注解的类
2. 解析：一旦Bean被发现，Spring将解析Bean的定义信息，包括Bean的作用域（如单例、原型）、生命周期回调（如@PostConstruct、@PreDestroy注解方法）、依赖注入的需求（通过@Autowired、@Resource等注解标记）等 —— BeanDefinition
3. 注册：Spring将Bean的定义信息注册到BeanDefinitionRegistry中。这是一个重要步骤，因为注册后的Bean定义将被用于后续的Bean实例化和依赖注入过程。此时，Bean还没有被实例化。

BeanDefinition

Spring在初始化过程中，先收集所有bean的元数据信息并注册，bean的元数据描述为接口BeanDefinition，该接口定义了你能想到的一切有关bean的属性信息

BeanDefinition衍生出一系列实现类

• AbstractBeanDefinition: 如同其他Spring类，大部分BeanDefinition接口的逻辑都由该抽象类实现
• GenericBeanDefinition: 是一站式、用户可见的bean definition；可见的bean definition意味着可以在该bean definition上定义post-processor来对bean进行操作
• RootBeanDefinition: 当bean definition存在父子关系的时候，RootBeanDefinition用来承载父元数据的角色（也可独立存在），同时它也作为一个可合并的bean definition使用，在Spring初始化阶段，所有的bean definition均会被（向父级）合并为RootBeanDefinition，子bean definition（GenericBeanDefinition/ChildBeanDefinition）中的定义会覆盖其父bean definition（由parentName指定）的定义
• AnnotatedBeanDefinition: 用来定义注解Bean Definition

BeanDefinitionHolder只是简单捆绑了BeanDefinition、bean-name、bean-alias，用于注册BeanDefinition及别名alias ^BeanDefinitionHolder

BeanRegistry

Bean的注册逻辑分为两步，一为BeanDefinition的注册，二为别名的注册

• BeanDefinition注册的定义在BeanDefinitionRegistry#registerBeanDefinition，其实现使用一个Map<String, BeanDefinition> 来保存bean-name和BeanDefinition的关系

• 别名的注册定义在AliasRegistry#registerAlias，其实现同样使用一个Map<String, String> 来保存别名alias-name和bean-name（或另一个别名alias-name）的关系

注意Bean的注册时机，通常应该在应用上下文的刷新过程之前进行(onRefresh())。一旦上下文被刷新，对Bean定义的任何修改可能不会被识别，或者可能会导致不一致的状态

Bean的实例化

BeanFactory

几个核心接口：

• AliasRegistry bean别名注册和管理
• BeanDefinitionRegistry bean元数据注册和管理
• SingletonBeanRegistry 单例bean注册和管理
• BeanFactory bean工厂，提供各种bean的获取及判断方法

通过上述的类依赖图，对于Bean的实例化，核心实现是在DefaultListableBeanFactory

DefaultListableBeanFactory - AbstractBeanFactory

bean的实例化过程发生在getBean调用阶段（对于singleton则发生在首次调用阶段），getBean的实现方法众多，我们追根溯源，找到最通用的方法AbstractBeanFactory#doGetBean

doGetBean

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

// org.springframework.beans.factory.support.AbstractBeanFactory
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
        @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {

    // 1. 获取真正的beanName
    final String beanName = transformedBeanName(name);
    Object bean;

    // 2. 尝试获取(提前曝光的)singleton bean实例（为了解决循环依赖）
    Object sharedInstance = getSingleton(beanName);
    
    // 3. 如果存在
    if (sharedInstance != null && args == null) { ... }
    
    // 4. 如果不存在
    else { ... }
    
    // 5. 尝试类型转换
    if (requiredType != null && !requiredType.isInstance(bean)) { ... }
    
    return (T) bean;
}

Bean Name的转换

在使用bean-name获取bean的时候，除了可以使用原始bean-name之外，还可以使用alias别名等，bean-name的转换则是将传入的’bean-name’一层层转为最原始的bean-name

• 函数canonicalName的作用则是利用别名注册aliasMap，将别名alias转为原始bean-name
• 函数transformedBeanName比较特殊，其是将FactoryBean的bean-name前缀 ‘&’ 去除

尝试获取单例

拿到原始的bean-name之后，便可以实例化bean或者直接获取已经实例化的singleton-bean

在获取singleton-bean的时候一般存在三种情况：1. 还未实例化(或者不是单例)；2. 已经实例化；3. 正在实例化；

• 对于 “1. 还未实例化” ，返回null即可，后续进行实例化动作
• 对于 “2. 已经实例化”，直接返回实例化的singleton-bean
• 对于 “3. 正在实例化”，会存在循环依赖问题

Spring中对于singleton-bean，有一个sharedInstance的概念，在调用getSingleton函数时，返回的不一定是完全实例化的singleton-bean，有可能是一个中间状态（创建完成，但未进行属性依赖注入及其他后处理逻辑），这种中间状态会通过getSingleton函数提前曝光出来，目的是为了解决循环依赖

因此，Spring通过提供三层缓存来解决循环依赖问题，并且可以通过这种机制实现诸多的PostProcessor增强Bean，例如AOP

• singletonObjects 缓存已经实例化完成的singleton-bean

• earlySingletonObjects 缓存正在实例化的、提前曝光的singleton-bean，用于处理循环依赖

• singletonFactories 缓存用于生成earlySingletonObject的 ObjectFactory

ObjectFactory，定义了一个用于创建、生成对象实例的工厂方法

1
2
3
4

@FunctionalInterface
public interface ObjectFactory<T> {
    T getObject() throws BeansException;
}

因此getSingleton的逻辑如下：

NOTE: 在提前暴露实体中，将相应的ObjectFactory放入了singletonFactories

FactoryBean的处理(sharedInstance存在的逻辑)

==sharedInstance不一定是我们所需要的bean实例==

例如，我们在定义Bean的时候可以通过实现FactoryBean接口来定制bean实例化的逻辑(实现FactoryBean)，通过注册FactoryBean类型的Bean，实例化后的原始实例类型同样为FactoryBean，但我们需要的是通过FactoryBean#getObject方法得到的实例，这需要针对FactoryBean做一些处理，即AbstractBeanFactory#getObjectForBeanInstance

Get the object for the given bean instance, either the bean instance itself or its created object in case of a FactoryBean. Now we have the bean instance, which may be a normal bean or a FactoryBean. If it’s a FactoryBean, we use it to create a bean instance.

该函数要实现的逻辑比较简单，如果sharedInstance是 FactoryBean，则使用getObject方法创建真正的实例

getObjectForBeanInstance是一个通用函数，并不只针对通过getSingleton得到的sharedInstance，任何通过缓存或者创建得到的 rawInstance，都需要经过getObjectForBeanInstance处理，拿到真正需要的 beanInstance

1
2
3
4
5
6
7
8

/**
 * @param beanInstance  sharedInstance / rawInstance，可能为FactoryBean
 * @param name            传入的未做转换的 bean name
 * @param beanName        对name做过转换后的原始 canonical bean name
 * @param mbd            合并后的RootBeanDefinition，下文会介绍
 */
protected Object getObjectForBeanInstance(
    Object beanInstance, String name, String beanName, RootBeanDefinition mbd)

getObjectBeanInstance

在这个判断逻辑中，如果入参name以’&‘开头则直接返回，这里兼容了一种情况，如果需要获取/注入FactoryBean而不是getObject生成的实例，则需要在bean-name/alias-name前加入'&'

对于singleton，FactoryBean#getObject的结果会被缓存到factoryBeanObjectCache，对于缓存中不存在或者不是singleton的情况，会通过FactoryBean#getObject生成 ^factorybeangetobject

FactoryBeanRegistrySupport#getObjectFromFactoryBean

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

protected Object getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess) {  
    if (factory.isSingleton() && this.containsSingleton(beanName)) {  
        synchronized(this.getSingletonMutex()) {  
            Object object = this.factoryBeanObjectCache.get(beanName);  
            if (object == null) {  
                object = this.doGetObjectFromFactoryBean(factory, beanName);  
                Object alreadyThere = this.factoryBeanObjectCache.get(beanName);  
                if (alreadyThere != null) {  
                    object = alreadyThere;  
                } else {  
                    if (shouldPostProcess) {  
                        if (this.isSingletonCurrentlyInCreation(beanName)) {  
                            return object;  
                        }  
  
                        this.beforeSingletonCreation(beanName);  
  
                        try {  
                            object = this.postProcessObjectFromFactoryBean(object, beanName);  
                        } catch (Throwable var14) {  
                            throw new BeanCreationException(beanName, "Post-processing of FactoryBean's singleton object failed", var14);  
                        } finally {  
                            this.afterSingletonCreation(beanName);  
                        }  
                    }  
  
                    if (this.containsSingleton(beanName)) {  
                        this.factoryBeanObjectCache.put(beanName, object);  
                    }  
                }  
            }  
  
            return object;  
        }  
    } else {  
        Object object = this.doGetObjectFromFactoryBean(factory, beanName);  
        if (shouldPostProcess) {  
            try {  
                object = this.postProcessObjectFromFactoryBean(object, beanName);  
            } catch (Throwable var17) {  
                throw new BeanCreationException(beanName, "Post-processing of FactoryBean's object failed", var17);  
            }  
        }  
  
        return object;  
    }  
}

对于Singleton:

• 首先从缓存中尝试获取，如获取失败，调用[doGetObjectFromFactoryBean](#FactoryBeanRegistrySupport doGetObjectFromFactoryBean “wikilink”)，其中内核是调用FactoryBean#getObject()方法
• 对于需要后处理的Bean，首先判断是否处于正在创建状态(isSingletonCurrentlyInCreation)，并且通过this.beforeSingletonCreate() this.afterSingletonCreation()将实际的BeanPostProcessor过程保护
• 对于BeanPostProcessor，调用this.postProcessObjectFromFactoryBean，其具体实现在[AbstractAutowireCapableBeanFactory#applyBeanPostProcessorAfterInitialization](#AbstractAutowireCapableBeanFactory applyBeanPostProcessorAfterInitialization “wikilink”)

FactoryBeanRegistrySupport#doGetObjectFromFactoryBean

AbstractAutowireCapableBeanFactory#applyBeanPostProcessorAfterInitialization

postProcessAfterInitialization函数可以对现有bean instance做进一步的处理，甚至可以返回新的bean instance，这就为bean的增强提供了一个非常方便的扩展方式

加载Bean实例 (sharedInstance不存在的逻辑)

Bean的加载/创建分为三大部分

1. 将BeanDefinition合并为RootBeanDefinition，类似类继承，子BeanDefinition属性会覆盖父BeanDefinition
2. 依次加载所依赖的bean，对于有依赖的情况，优先递归加载依赖的bean
3. 按照不同的bean类型，根据BeanDefinition的定义进行加载/创建

BeanDefinition合并 (RootBeanDefinition)

在AbstractBeanFactory#getMergedLocalBeanDefinition中执行核心逻辑

加载dependes-On beans

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
    // 遍历所有的依赖
    for (String dep : dependsOn) {
        // 检测循环依赖
        if (isDependent(beanName, dep)) { /* throw exception */ }
        // 注册依赖关系
        registerDependentBean(dep, beanName);
        // 递归getBean，加载依赖bean
        try { getBean(dep); }
        catch (NoSuchBeanDefinitionException ex) { /* throw exception */ }
    }
}

该过程中涉及两个中间态

• dependentBeanMap 存储哪些bean依赖了我（哪些bean里注入了我） 如果 beanB -> beanA, beanC -> beanA，key为beanA，value为[beanB, beanC]

• dependenciesForBeanMap 存储我依赖了哪些bean（我注入了哪些bean） 如果 beanA -> beanB, beanA -> beanC，key为beanA，value为[beanB, beanC]

加载singleton bean实例

1
2
3
4
5
6
7
8

if (mbd.isSingleton()) {
    sharedInstance = getSingleton(beanName, () -> {
        // singletonFactory - ObjectFactory
        try { return createBean(beanName, mbd, args); }
        catch (BeansException ex) {    destroySingleton(beanName);    throw ex; }
    });
    bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}

其中核心为createBean与getObjectForBeanInstance

• createBean 根据BeanDefinition的内容，创建/初始化 bean instance
• #getObjectBeanInstance 主要处理FactoryBean

createBean被包装在lambda(singletonFactory)，重写ObjectFactory#getObject()，作为[getSingleton](#DefaultSingletonBeanRegistry getSingleton(String, ObjectFactory) “wikilink”)的参数

DefaultSingletonBeanRegistry#getSingleton(String, ObjectFactory)

同样的，会先在缓存中查找该singleton，如果不存在，创建的核心逻辑在于[createBean](#AbstractAutowireCapableBeanFactory createBean “wikilink”)

AbstractAutowireCapableBeanFactory#createBean

1. resolveBeanClass 这一步骤用于锁定bean class，在没有显示指定beanClass的情况下，使用className加载beanClass
2. 验证method overrides ==在BeanDefinitionReader 中有提到过lookup-method及replace-method，该步骤是为了确认以上两种配置中的method是否存在==
3. 执行InstantiationAwareBeanPostProcessor前处理器(postProcessBeforeInstantiation) 如果这个步骤中生成了"代理"bean instance，则会有一个短路操作，直接返回该bean instance而不再执行doCreate，其中的核心逻辑为调用this.applyBeanPostProcessorsBeforeInstantiation() ^fcb215

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

try {
    // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
    Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
    if (bean != null) {
          // 如果这里生成了代理的bean instance会直接返回
        return bean;
    }
} cache (Throwable ex) { // throw exception }

try {
  // 创建bean instance
  Object beanInstance = doCreateBean(beanName, mbdToUse, args);
  // ...
}

4. doCreateBean (AbstractAutowireCapableBeanFactory) 真正bean的创建及初始化过程在此处实现

doCreateBean

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException {  
    BeanWrapper instanceWrapper = null;  
    if (mbd.isSingleton()) {  
        instanceWrapper = (BeanWrapper)this.factoryBeanInstanceCache.remove(beanName);  
    }  
  
    if (instanceWrapper == null) {  
        instanceWrapper = this.createBeanInstance(beanName, mbd, args);  
    }  
  
    Object bean = instanceWrapper.getWrappedInstance();  
    Class<?> beanType = instanceWrapper.getWrappedClass();  
    if (beanType != NullBean.class) {  
        mbd.resolvedTargetType = beanType;  
    }  
  
    synchronized(mbd.postProcessingLock) {  
        if (!mbd.postProcessed) {  
            try {  
                this.applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);  
            } catch (Throwable var17) {  
                throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Post-processing of merged bean definition failed", var17);  
            }  
  
            mbd.markAsPostProcessed();  
        }  
    }  
  
    boolean earlySingletonExposure = mbd.isSingleton() && this.allowCircularReferences && this.isSingletonCurrentlyInCreation(beanName);  
    if (earlySingletonExposure) {  
        if (this.logger.isTraceEnabled()) {  
            this.logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");  
        }  
  
        this.addSingletonFactory(beanName, () -> {  
            return this.getEarlyBeanReference(beanName, mbd, bean);  
        });  
    }  
  
    Object exposedObject = bean;  
  
    try {  
        this.populateBean(beanName, mbd, instanceWrapper);  
        exposedObject = this.initializeBean(beanName, exposedObject, mbd);  
    } catch (Throwable var18) {  
        if (var18 instanceof BeanCreationException bce) {  
            if (beanName.equals(bce.getBeanName())) {  
                throw bce;  
            }  
        }  
  
        throw new BeanCreationException(mbd.getResourceDescription(), beanName, var18.getMessage(), var18);  
    }  
  
    if (earlySingletonExposure) {  
        Object earlySingletonReference = this.getSingleton(beanName, false);  
        if (earlySingletonReference != null) {  
            if (exposedObject == bean) {  
                exposedObject = earlySingletonReference;  
            } else if (!this.allowRawInjectionDespiteWrapping && this.hasDependentBean(beanName)) {  
                String[] dependentBeans = this.getDependentBeans(beanName);  
                Set<String> actualDependentBeans = new LinkedHashSet(dependentBeans.length);  
                String[] var12 = dependentBeans;  
                int var13 = dependentBeans.length;  
  
                for(int var14 = 0; var14 < var13; ++var14) {  
                    String dependentBean = var12[var14];  
                    if (!this.removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {  
                        actualDependentBeans.add(dependentBean);  
                    }  
                }  
  
                if (!actualDependentBeans.isEmpty()) {  
                    throw new BeanCurrentlyInCreationException(beanName, "Bean with name '" + beanName + "' has been injected into other beans [" + StringUtils.collectionToCommaDelimitedString(actualDependentBeans) + "] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");  
                }  
            }  
        }  
    }  
  
    try {  
        this.registerDisposableBeanIfNecessary(beanName, bean, mbd);  
        return exposedObject;  
    } catch (BeanDefinitionValidationException var16) {  
        throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Invalid destruction signature", var16);  
    }  
}

可以将该流程细分为如下：

1. [创建Bean实体](#创建Bean实体 AbstractAutowireCapableBeanFactory createBeanInstance “wikilink”)
2. [BeanDefinition后处理](#BeanDefinition后处理 - AbstractAutowireCapableBeanFactory applyMergedBeanDefinitionPostProcessors “wikilink”)
3. 提前暴露实体
4. [属性注入](#属性注入 - AbstractAutowireCapableBeanFactory populateBean “wikilink”)
5. [初始化](#初始化 - AbstractAutowireCapableBeanFactory initializeBean “wikilink”)
6. [注册Disposable](#注册Disposable - AbstractBeanFactory registerDisposableBeanIfNecessary “wikilink”)

创建Bean实体 - AbstractAutowireCapableBeanFactory#createBeanInstance

1. instanceSupplier 从上面的流程图可以看出，创建bean实体不一定会使用到构造函数，可以使用Supplier的方式
2. factory method 工厂模式 @Configuration + @Bean的实现方式就是factory-bean + factory-method [对应的参数获取](#ConstructorResolver resolvePreparedArguments “wikilink”)
3. 有参构造函数 AbstractAutowireCapableBeanFactory#autowireConstructor -> [ConstructorResolver#autowireConstructor](#**ConstructorResolver autowireConstructor** “wikilink”)
4. 无参构造函数 与有参构造创建过程一致，除了不需要参数的依赖注入，使用默认无参构造函数进行实例化

ConstructorResolver#resolvePreparedArguments

使用指定（类）bean的（静态）方法创建bean实体的逻辑在ConstructorResolver#instantiate(String, RootBeanDefinition, Object, Method, args)，而真正的逻辑在SimpleInstantiationStrategy#instantiate(RootBeanDefinition, String, BeanFactory, Object, Method, Object…)，其核心的执行逻辑非常简单，有了方法factoryMethod(factoryBean)及入参args，便可以调用该方法创建bean实体

1

Object result = factoryMethod.invoke(factoryBean, args);

factoryBean可以通过beanFactory.getBean获取到（正是当前在讲的逻辑），factoryMethod可以通过反射获取到，而入参args就从ConstructorResolver#resolvePreparedArguments中获取，即是Spring中依赖注入的核心实现

该函数的作用是将BeanDefinition中定义的入参转换为需要的参数(==将BeanDefinitionReader中封装的对象转换==)

More in blogs

ConstructorResolver#autowireConstructor

同样的，调用ConstructorResolver#resolvePreparedArguments进行参数的解析和转换(参数的依赖注入)，然后调用 [ConstructorResolver#instantiate](#ConstructorResolver instantiate “wikilink”) 来创建Bean实例

ConstructorResolver#instantiate

内部并没有统一利用反射技术直接使用构造函数创建，而是通过InstantiationStrategy.instantiate进行创建

• 没有设置override-method时，直接使用构造函数创建
• 设置了override-method时，使用cglib技术构造代理类，并代理override方法

Spring默认的实例化策略为CglibSubclassingInstantiationStrategy

BeanDefinition后处理 - AbstractAutowireCapableBeanFactory#applyMergedBeanDefinitionPostProcessors

在属性注入之前提供一次机会来对BeanDefinition进行处理，内部执行所有注册MergedBeanDefinitionPostProcessor的postProcessMergedBeanDefinition方法

[!hint] MergedBeanDefinitionPostProcessor MergedBeanDefinitionPostProcessor 是一个特定类型的 BeanPostProcessor。MergedBeanDefinitionPostProcessor 的 postProcessMergedBeanDefinition 方法允许在实例化bean之后但在设置bean属性之前，对bean的定义（BeanDefinition）进行后处理。这个阶段是用于修改或增强bean定义的，例如，可以解析注解并相应地修改 BeanDefinition 的属性。

对于MergedBeanDefinitionPostProcessor的实现类AutowiredAnnotationBeanPostProcessor，其内部方法AutowiredAnnotationBeanPostProcessor#buildAutowiringMetadata 实现了两个注解类的解析 @Value 及 @Autowired ，找到注解修饰的Filed或者Method并缓存，具体逻辑在[属性注入](#属性注入 - AbstractAutowireCapableBeanFactory populateBean “wikilink”) ^autowiredAnnotationBeanPostProcessor1

提前暴露实体

通过将AbstractAutowireCapableBeanFactory#getEarlyBeanReference封装为ObjectFactory，调用DefaultSingletonBeanRegistry#addSingletonFactory，将该ObjectFactory缓存在DefaultSingletonBeanRegistry.singletonFactories中，在getBean逻辑中的getSingleton会执行ObjectFactory将singleton提前暴露 ==此处即为何时添加ObjectFactory进入singletonFactories中，解决循环依赖==

此时暴露的singleton-bean仅完成了bean的实例化，属性注入、初始化等逻辑均暂未执行

属性注入 - AbstractAutowireCapableBeanFactory#populateBean

在[创建Bean实体](#创建Bean实体 - AbstractAutowireCapableBeanFactory createBeanInstance “wikilink”)中介绍了factory method方式及有参构造函数方式的参数注入逻辑，除此之外还有一种注入便是属性注入

流程中出现了两次InstantiationAwareBeanPostProcessor，在第一次出现中调用的postProcessorAfterInstantiation也与前面的InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation相同，拥有短路操作：如果该步骤生成了"代理"bean instance，直接返回该bean instance而不再执行后续的doCreate；如果有任意一个InstantiationAwareBeanPostProcessor的postProcessAfterInstantiation方法返回false，则会跳出属性注入的逻辑，官方对此的解释如下

Give any InstantiationAwareBeanPostProcessors the opportunity to modify the state of the bean before properties are set. This can be used, for example, to support styles of field injection.

autowireByName及autowireByType方法作为"候补"补充BeanDefinition的propertyValues

PropertyValue中记录了需要注入的属性信息及需要注入的属性值，那BeanDefinition的propertyValues都来自哪里？xml中的bean配置、自定义的BeanDefinition等

通过注解修饰的属性(方法)通过InstantiationAwareBeanPostProcessor#postProcessProperties进行注入 -> ==AutowiredAnnotationBeanPostProcessor#postProcessProperties & CommonAnnotationBeanPostProcessor#postProcessProperties==

最后，通过AbstractAutowireCapableBeanFactory#applyPropertyValues 将PropertyValue中记录的需要注入的属性，已经依赖的类型（String、RuntimeBeanReference、等），根据不同的类型解析依赖的bean并设置到对应的属性上（==此过程与DefaultListableBeanFactory#doResolveDependency相似==）

初始化 - AbstractAutowireCapableBeanFactory#initializeBean

以上，完成了bean实例的创建和属性注入，之后还有一些初始化的方法，比如各种Aware的setXxx是如何调用的、@PostConstruct是怎么调用的？

注册Disposable - AbstractBeanFactory#registerDisposableBeanIfNecessary

至此，终于完成了bean实例的创建、属性注入以及之后的初始化，此后便可以开始使用了

在使用Spring的过程中经常还会碰到设置销毁逻辑的情况，如数据库连接池、线程池等等，在Spring销毁bean的时候还需要做一些处理，类似于C++中的析构

在bean的创建逻辑中，最后一个步骤则是注册bean的销毁逻辑（DisposableBean）

销毁逻辑的注册有几个条件

1. 非prototype（singleton或者注册的scope）
2. 非NullBean
3. 指定了destroy-method（如xml中指定或者BeanDefinition中直接设置）或者存在**@PreDestroy** 注解的方法（CommonAnnotationBeanPostProcessor.requiresDestruction）

1

if (!mbd.isPrototype() && requiresDestruction(bean, mbd))

满足以上条件的bean会被封装为DisposableBeanAdapter，并注册在DefaultSingletonBeanRegistry.disposableBeans中

加载prototype bean实例

1
2
3
4
5
6
7
8
9

else if (mbd.isPrototype()) {
    Object prototypeInstance = null;
    try {
        beforePrototypeCreation(beanName);
        prototypeInstance = createBean(beanName, mbd, args);
    }
    finally { afterPrototypeCreation(beanName);    }
    bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}

prototype bean的创建与singleton bean类似，只是不会缓存创建完成的bean

加载其他scope bean实例

scope，即作用域，或者可以理解为生命周期

上文介绍了singleton-bean及prototype-bean的创建过程，严格意义上讲以上两种都是一种特殊的scope-bean，分别对应ConfigurableBeanFactory#SCOPE_SINGLETON及ConfigurableBeanFactory#SCOPE_PROTOTYPE，前者作用域为整个IOC容器，也可理解为单例，后者作用域为所注入的bean，每次注入(每次触发getBean)都会重新生成

Spring中还提供很多其他的scope，如WebApplicationContext#SCOPE_REQUEST或WebApplicationContext#SCOPE_SESSION，前者作用域为一次web request，后者作用域为一个web session周期

自定义scope的bean实例创建过程与singleton bean的创建过程十分相似，需要实现Scope的get方法(org.springframework.beans.factory.config.Scope#get)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

else {
    String scopeName = mbd.getScope();
    final Scope scope = this.scopes.get(scopeName);
    if (scope == null) { /* throw exception */ }
    try {
        Object scopedInstance = scope.get(beanName, () -> {
            beforePrototypeCreation(beanName);
            // createBean被封装在Scope#get函数的lambda参数ObjectFactory中
            try { return createBean(beanName, mbd, args); }
            finally { afterPrototypeCreation(beanName); }
        });
        bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
    } catch (IllegalStateException ex) { /* throw exception */}
}

Scope接口除了get方法之外，还有一个remove方法，前者用于定义bean的初始化逻辑，后者用于定义bean的销毁逻辑

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

public interface Scope {
  /**
   * Return the object with the given name from the underlying scope
   */
  Object get(String name, ObjectFactory<?> objectFactory);
  
   /**
   * Remove the object with the given name from the underlying scope.
   */
  Object remove(String name);
}

WebApplicationContext#SCOPE_SESSION对应的Scope实现见org.springframework.web.context.request.SessionScope

WebApplicationContext#SCOPE_REQUEST对应的Scope实现见org.springframework.web.context.request.RequestScope

以上两种Scope实现都较为简单，前者将初始化的bean存储在request attribute中，后者将初始化的bean存储在http session中

尝试类型转换

以上，完成了bean的创建、属性的注入、dispose逻辑的注册，但获得的bean类型与实际需要的类型可能依然不相符，在最终交付bean之前（getBean）还需要进行一次类型转换，使用PropertyEditor进行类型转换，将bean转换为真正需要的类型后，便完成了整个getBean的使命

Bean销毁过程

bean的创建过程始于DefaultListableBeanFactory#getBean，销毁过程则终于ConfigurableApplicationContext#close，跟踪下去，具体的逻辑在DefaultSingletonBeanRegistry#destroySingletons

1. DefaultSingletonBeanRegistry.disposableBeans 需要注册销毁逻辑的bean会被封装为DisposableBeanAdapter并缓存在此处
2. DefaultSingletonBeanRegistry.dependentBeanMap 对于存在依赖注入关系的bean，会将bean的依赖关系缓存在此处（dependentBeanMap: 哪些bean依赖了我; dependenciesForBeanMap: 我依赖了哪些bean）

从上图中可以看出，bean的销毁顺序与创建顺序正好相反，如果有 beanA –dependsOn–> beanB –> beanC ，创建（getBean）时一定是beanC -> beanB -> beanA，销毁时一定是 beanA -> beanB -> beanC，以此避免因为依赖关系造成的一些异常情况

循环依赖

earlySingletonObject是用来解决循环依赖的问题，具体时机是在实例化完后属性注入之前，会提前将当前的bean实体暴露出来，以防止在属性注入过程中所注入的bean又依赖当前的bean造成的类似"死锁"的状态

但是存在以下情况，Spring依旧会陷入循环依赖死锁：

• 显式设置dependsOn的循环依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

@DependsOn("beanB")
@Component
public class BeanA {}

@DependsOn("beanC")
@Component
public class BeanB {}

@DependsOn("beanA")
@Component
public class BeanC {}

• 构造函数循环依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

@Component
public class BeanA {
    public BeanA(BeanB beanB) {
    }
}

@Component
public class BeanB {
    public BeanB(BeanC beanC) {
    }
}

@Component
public class BeanC {
    public BeanC(BeanA beanA) {
    }
}

• factory-method循环依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

@Bean
public BeanA beanA(BeanB beanB) {
    return new BeanA();
}

@Bean
public BeanB beanB(BeanC beanC) {
    return new BeanB();
}

@Bean
public BeanC beanC(BeanA beanA) {
    return new BeanC();
}

• 上述三种依赖混合

只要一个循环依赖中的所有bean，其依赖关系都需要在创建bean实例之前进行解决，此循环依赖则一定无解

要打破无解的循环依赖，在构成循环依赖的一个环中，只需要保证其中至少一个Bean的依赖在该Bean创建且暴露earlySingleton之后处理即可，即在属性注入阶段进行属性依赖的处理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@Component
public class BeanA {
    @Autowired
    private BeanB beanB;
}

@Component
public class BeanB {
    public BeanB(BeanC beanC) {
    }
}

@Bean
public BeanC beanC(BeanA beanA) {
    return new BeanC();
}

以"bean创建且暴露earlySingleton"为节点，在此之前处理依赖的有instance supplier parameter、factory method parameter、constructor parameter、等，在此之后处理的依赖有 class property、setter parameter等

ApplicationContext

BeanFactory实现了IoC的基础能力，而ApplicationContext是BeanFactory的子类，除了继承IoC的基础能力外

• 支持国际化 (MessageSource)
• 支持资源访问 (ResourcePatternResolver)
• 事件机制 (ApplicationEventPublisher)
• 默认初始化所有Singleton
• 提供扩展能力

无论何种功能的ApplicationContext，在做完基本的初始化后均会调用AbstractApplicationContext#Refresh

AbstractApplicationContext#Refresh

准备上下文 - AbstractApplicationContext#prepareRefresh

该部分主要实现对上下文的准备工作，其主要涉及到两个接口AbstractApplicationContext#initPropertySources及ConfigurablePropertyResolver#validateRequiredProperties，前者由子类实现，用于初始化PropertySource；后者用于对必要属性进行验证

1
2
3
4
5
6
7

public class MyClasspathXmlApplicationContext extends ClassPathXmlApplicationContext {
    @Override
    protected void initPropertySources() {
        super.initPropertySources();
        getEnvironment().setRequiredProperties("runtimeEnv");
    }
}

重写initPropertySources方法，并添加runtimeEnv为必须的环境变量属性，如此在系统启动的时候便会进行检测，对于不存在任何一个必要环境变量的情况均会抛出异常终止启动

加载BeanFactory - AbstractApplicationContext#obtainFreshBeanFactory

该函数内部实现比较简单，重点在refreshBeanFactory，该函数同样由子类实现

对于AbstractRefreshableApplicationContext，refreshBeanFactory基本步骤为

1. 创建BeanFactory (DefaultListableBeanFactory)
2. 设置BeanFactory
3. 加载BeanDefinition

在第3步中，AbstractXmlApplicationContext的实现则是对xml配置文件的解析及加载；AnnotationConfigWebApplicationContext的实现则是对class文件的扫描并加载，以及其他基于AbstractRefreshableApplicationContext的ApplicationContext实现

对于GenericApplicationContext，BeanFactory的创建及BeanDefinition的加载在refresh调用之前早已完成，refreshBeanFactory的实现则是对BeanFactory加载状态的简单校验

AbstractRefreshableApplicationContext & GenericApplicationContext

AbstractRefreshableApplicationContext

对于继承自 AbstractRefreshableApplicationContext 的上下文，例如 ClassPathXmlApplicationContext 或 AnnotationConfigApplicationContext，它们通过覆盖 refreshBeanFactory() 方法来实现具体的 BeanDefinition 加载逻辑。这些上下文类型专门用于从外部资源（如 XML 文件、Java 配置类等）加载配置信息，并将这些配置信息解析为一组 BeanDefinition，然后注册到内部的 BeanFactory 中。这个过程通常发生在上下文的 refresh() 方法调用过程中（我们正在讨论的），这个方法不仅负责加载和注册 BeanDefinition，还包括初始化单例bean、处理别名定义、注册BeanPostProcessor等一系列容器启动时的活动。

[!QUOTE] refresh()关键步骤 ^configurerRelated

1. 创建 BeanFactory：AbstractRefreshableApplicationContext 首先会创建一个新的 BeanFactory 实例，这通常是一个 DefaultListableBeanFactory 实例。这个 BeanFactory 实现了 BeanDefinitionRegistry 接口，使得它能够注册 BeanDefinition。
2. ==加载 BeanDefinition：接着，上下文会调用特定的方法（例如，对于基于 XML 的配置，会使用 XmlBeanDefinitionReader；对于基于注解的配置，会使用 AnnotatedBeanDefinitionReader 和 ClassPathBeanDefinitionScanner）来加载 BeanDefinition。这些 Reader 和 Scanner 实现了 BeanDefinitionRegistry 接口的 registerBeanDefinition 方法来实际完成注册工作。==
3. 刷新 BeanFactory：加载完所有 BeanDefinition 后，AbstractRefreshableApplicationContext 会对 BeanFactory 进行刷新，这涉及到预实例化单例、注册 BeanPostProcessor、初始化剩余的非懒加载单例等一系列操作。
4. 发布事件：在整个容器刷新过程中，还会发布各种应用事件，如 ContextRefreshedEvent，允许应用中的其他组件对这些事件作出响应。

通过上述步骤，AbstractRefreshableApplicationContext 完成了 BeanDefinition 的加载、注册以及整个 Spring 容器的初始化和刷新工作。在这个过程中，BeanDefinitionRegistry 接口扮演了 BeanDefinition 注册的关键角色

GenericApplicationContext

GenericApplicationContext 直接实现了 BeanDefinitionRegistry 接口，使得它可以在运行时动态注册 BeanDefinition。与 AbstractRefreshableApplicationContext 的子类不同，GenericApplicationContext 并不专门依赖于外部资源来加载 BeanDefinition。相反，它提供了一套程序化的接口，允许开发者直接在代码中通过调用 registerBeanDefinition(String beanName, BeanDefinition beanDefinition) 方法来注册 BeanDefinition。这种方式使得 GenericApplicationContext 非常灵活，适用于那些需要在运行时动态调整 Spring 配置的场景。

关系和区别

• 加载方式的区别：AbstractRefreshableApplicationContext 的子类通常通过解析配置资源（XML、注解等）来加载 BeanDefinition，而 GenericApplicationContext 允许以编程方式直接注册 BeanDefinition。
• 使用场景的区别：AbstractRefreshableApplicationContext 的子类适合于静态配置资源的场景，其中配置信息在应用启动时已经确定。GenericApplicationContext 更适合于动态配置的场景，比如基于条件的 BeanDefinition 注册或运行时的配置调整。
• 刷新容器的能力：虽然两者都可以通过 refresh() 方法来刷新应用上下文，但 AbstractRefreshableApplicationContext 的子类通常在设计时就考虑了完整的容器刷新流程（包括重新加载配置资源），而 GenericApplicationContext 刷新主要是为了应用新注册的 BeanDefinition。==前者会重置BeanFactory而后者不会==

填充部分扩展 - AbstractApplicationContext#prepareBeanFactory

该函数执行以下逻辑

1. 设置BeanFactory的ClassLoader
2. 注册默认BeanExpressionResolver，用于依赖注入时SpEL的支持
3. 注册默认PropertyEditor，用于依赖注入时对参数的解析转换
4. 注册几个特殊Aware的处理逻辑
5. 注册AspectJ相关的几个处理器，用于AOP的支持
6. 注册几个特殊的BeanDefinition

==2-3 的核心逻辑在于解析依赖的值，DefaultListableBenFactory#doResolveDependency==

注册几个特殊Aware的处理逻辑

在Bean实例化、注入依赖之后会对Bean进行[最后的初始化](#初始化 - AbstractAutowireCapableBeanFactory initializeBean “wikilink”)，调用相应的setter方法分别针对BeanNameAware、BeanClassLoaderAware、BeanFactoryAware进行处理

在该函数中，会注册几个特殊的BeanPostProcessor

1

beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));

其实现了postProcessBeforeInitialization方法，内部调用ApplicationContextAwareProcessor#invokeAwareInterfaces针对另外的几类Aware进行了处理

除此之外，Spring会将上述几类Aware设置为ignoreDependencyInterface，这意味着以上几类Bean的注入只能通过Aware的方式而不能通过其他属性依赖注入的方式（属性注入、函数参数注入等）

注册特殊的Bean

在使用Spring时，是否有过直接注入BeanFactory亦或是ResourceLoader，这些bean正是在这里被Spring注册进去的，除以上外Spring还注入了

• BeanFactory
• ResourceLoader
• ApplicationEventPublisher
• ApplicationContext
• Environment
• systemProperties - Environment#.getSystemProperties:Map<String, Object>
• systemEnvironment - Environment#.getSystemEnvironment:Map<String, Object>

  AbstractApplicationContext#refresh#postProcessBeanFactory()

对于不同的实现类，注册相应的BeanPostProcessor，例如ServletWebServerApplicationContext

激活BeanFactoryPostProcessor - AbstractApplicationContext#invokeBeanFactoryPostProcessors

其内部实现在PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors

BeanFactoryPostProcessor的定义非常简单，其postProcessBeanFactory方法允许在bean实例化前对BeanFactory做一些额外的设置

1
2
3
4
5
6
7
8
9

public interface BeanFactoryPostProcessor {
    /**
     * Modify the application context's internal bean factory after its standard
     * initialization. All bean definitions will have been loaded, but no beans
     * will have been instantiated yet. This allows for overriding or adding
     * properties even to eager-initializing beans.
     */
    void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}

核心逻辑如下

其中涉及两种类型，BeanDefinitionRegistryPostProcessor及BeanFactoryPostProcessor，前者为后者的子类，BeanDefinitionRegistryPostProcessors提供了额外的接口postProcessBeanDefinitionRegistry，用于更加方便地动态地注册额外的BeanDefinition (registryProcessor.postProcessBeanDefinitionRegistry(registry))，如读取配置文件（json、properties、yml）并解析（或者任何其他的形式），并通过该接口注册相应的BeanDefinition，基于Spring Boot Starter的很多框架均使用该方式进行bean的注册

以上流程图可以看出，优先执行BeanDefinitionRegistryPostProcessor#postProcessBeanDefinitionRegistry，再执行BeanFactoryPostProcessor#postProcessBeanFactory，各自内部优先执行PriorityOrdered实现，再执行Ordered实现，最后执行无任何排序的实现

注册BeanPostProcessor - AbstractApplicationContext#registerBeanPostProcessors

其内部实现在PostProcessorRegistrationDelegate#registerBeanPostProcessors b

BeanPostProcessor

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public interface BeanPostProcessor {
    /**
     * Apply this BeanPostProcessor to the given new bean instance before any bean
     * initialization callbacks (like InitializingBean's afterPropertiesSet
     * or a custom init-method). 
     * The returned bean instance may be a wrapper around the original.
     */
    @Nullable
    default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }

    /**
     * Apply this BeanPostProcessor to the given new bean instance after any bean
     * initialization callbacks (like InitializingBean's afterPropertiesSet
     * or a custom init-method).
     * The returned bean instance may be a wrapper around the original.
     */
    @Nullable
    default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }
}

1. postProcessBeforeInitialization方法在调用bean的init-method之前执行
2. postProcessAfterInitialization方法在调用bean的init-method之后执行
3. 任何一个方法可对现有bean实例做进一步的修改
4. 任何一个方法可返回新的bean实例，用来替代现有的bean实例

第四点即是AOP生成当前Bean代理的方法

InstantiationAwareBeanPostProcessor

该接口继承自BeanPostProcessor，其同样有两个方法，一个在创建bean实例之前调用([createBean](#AbstractAutowireCapableBeanFactory createBean “wikilink”))，一个在创建bean实例之后、属性注入之前调用([属性注入](#属性注入 - AbstractAutowireCapableBeanFactory populateBean “wikilink”))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

public interface InstantiationAwareBeanPostProcessor extends BeanPostProcessor {  
    @Nullable  
    default Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {  
        return null;  
    }  
  
    default boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {  
        return true;  
    }  
  
    @Nullable  
    default PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) throws BeansException {  
        return pvs;  
    }  
}

AbstractApplicationContext#registerBeanPostProcessors，其内部逻辑与BeanFactoryPostProcessor的注册逻辑类似：

1. 找到所有BeanPostProcessor并实例化
2. 按照实现的Ordered接口分别放入priorityOrderedPostProcessors、orderedPostProcessors、nonOrderedPostProcessors并各自排序
3. 如果实现了MergedBeanDefinitionPostProcessor则放入internalPostProcessors并排序
4. 按顺序依次注册priorityOrderedPostProcessors、orderedPostProcessors、nonOrderedPostProcessors
5. 最后注册internalPostProcessors

MergedBeanDefinitionPostProcessor其有一个接口postProcessMergedBeanDefinition，在bean实例化完成后属性注入之前被调用，可以用来对当前的BeanDefinition做进一步的修改，如增加PropertyValue等，实现特殊的属性依赖注入，参考[BeanDefinition后处理](#BeanDefinition后处理 - AbstractAutowireCapableBeanFactory applyMergedBeanDefinitionPostProcessors “wikilink”)与[属性注入](#属性注入 - AbstractAutowireCapableBeanFactory populateBean “wikilink”)

初始化MessageSource - AbstractApplicationContext#initMessageSource

Spring的MessageSource提供了国际化能力，在开发者未注册MessageSource的情况下Spring会提供一个默认的DelegatingMessageSource

初始化ApplicationEventMulticaster - AbstractApplicationContext#initApplicationEventMulticaster

Spring提供了一套事件（ApplicationEvent）的发布&订阅机制，开发者可自定义事件（继承ApplicationEvent），注册事件监听器来订阅消费事件（实现ApplicationListener 或使用@EventListener 注解），并使用ApplicationEventPublisher（直接依赖注入或者使用ApplicationEventPublisherAware）发送事件，使用示例可参考https://www.baeldung.com/spri…

其实ApplicationContext实现了ApplicationEventPublisher，跟踪其publishEvent方法会发现，最终调用了AbstractApplicationContext#applicationEventMulticaster.multicastEvent，开发者可以自行注册一个ApplicationEventMulticaster，如果没有Spring会提供一个默认的SimpleApplicationEventMulticaster

SimpleApplicationEventMulticaster#multicastEvent的逻辑比较简单，会根据事件的类型找到可以处理的所有ApplicationListener，依次调用它们的onApplicationEvent方法消费事件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

@Override
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
    ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
    Executor executor = getTaskExecutor();
    for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
        if (executor != null) {
      // 设置了executor，则异步执行
            executor.execute(() -> invokeListener(listener, event));
        }
        else {
      // 否则同步执行
            invokeListener(listener, event);
        }
    }
}

默认情况下会同步、顺序的调用listeners的onApplicationEvent方法，只有设置了executor才会异步调用，不过这样的控制粒度比较粗，要么全部同步消费要么全部异步消费，比较细粒度的控制事件的消费有几种常用方法

1. 使用@Async注解，独立控制某一listener异步消费（https://www.baeldung.com/spri…）
2. 自行编码，将onApplicationEvent逻辑放在线程中执行
3. 注册自定义的ApplicationEventMulticaster，内部实现自己的同步、异步Event处理逻辑

注册ApplicationListener - AbstractApplicationContext#registerListeners

这里的逻辑比较简单

1. 在BeanFactory中找到ApplicationListener类型的bean并实例化
2. 调用ApplicationEventMulticaster#addApplicationListenerBean方法将ApplicationListeners注册进去

初始化所有非Lazy Bean - AbstractApplicationContext#finishBeanFactoryInitialization

对于Singleton Bean而言，实例化发生在首次getBean，但你是否有疑惑，我们只是注册了众多Singleton Bean，但在Spring初始化完成后所有的Singleton Bean（Lazy Bean除外）均已经完成实例化

回到AbstractApplicationContext#finishBeanFactoryInitialization，该函数会实现几个逻辑

1. 如果自定义了ConversionService(另一种注入类型转换的方式)类型bean且bean-name为conversionService，则将其注册到BeanFactory中
2. 如果BeanFactory中不存在EmbeddedValueResolver（PropertyResourceConfigurer会注册一个PlaceholderResolvingStringValueResolver到BeanFactory中），则会注册一个默认的StringValueResolver用来处理 ${ ... }类型的值（Environment#resolvePlaceholders）
3. 找到所有非Lazy的Singleton BeanDefinition进行实例化（getBean）
   1. 如果是FactoryBean，则在bean name前加上’&’，并实例化该FactoryBean，随后实例化真实的bean
   2. 如果不是FactoryBean，则直接实例化该bean
4. 执行SmartInitializingSingleton实现类的afterSingletonsInstantiated方法

Refresh的后续动作 - AbstractApplicationContext#finishRefresh

除了一些中间状态需要清理外，还有两件比较特殊的地方

LifecycleProcessor - AbstractApplicationContext#initLifecycleProcessor

Spring提供了LifecycleProcessor用于监听BeanFactory的refresh及close，在BeanFactory的各阶段会调用LifecycleProcessor的onFresh及onClose方法

开发者可以自行注册LifecycleProcessor类型的bean，bean-name必须为"lifecycleProcessor"，否则Spring会提供一个默认的DefaultLifecycleProcessor

之后则会触发LifecycleProcessor的onFresh方法

除此之外，还可以监听ContextRefreshedEvent及ContextClosedEvent消息

refresh事件

在BeanFactory初始化完成后，则会发出ContextRefreshedEvent事件

BeanFactory的销毁 - AbstractApplicationContext#registerShutdownHook

该函数用来注册BeanFactory的销毁逻辑

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

public void registerShutdownHook() {  
    if (this.shutdownHook == null) {  
        this.shutdownHook = new Thread("SpringContextShutdownHook") {  
            public void run() {  
                synchronized(AbstractApplicationContext.this.startupShutdownMonitor) {  
                    AbstractApplicationContext.this.doClose();  
                }  
            }  
        };  
        Runtime.getRuntime().addShutdownHook(this.shutdownHook);  
    }  
  
}

其直接使用了java的addShutdownHook函数，在jvm进程正常退出的时候触发

AbstractApplicationContext#doClose函数定义了BeanFactory具体的销毁过程

1. 发出ContextClosedEvent事件
2. 触发LifecycleProcessor的onClose方法
3. 销毁bean，细节参考Bean销毁过程
4. 由子类实现的AbstractApplicationContext#closeBeanFactory及AbstractApplicationContext#onClose方法

ASIDE

• BeanDefinition的加载在[AbstractApplicationContext#obtainFreshBeanFactory](#加载BeanFactory - AbstractApplicationContext obtainFreshBeanFactory “wikilink”)中实现
• TODO
  • #{ ... }类型值的解析由StandardBeanExpressionResolve实现
  • ${ ... }类型值的解析由PlaceholderResolvingStringValueResolver实现
  • Spring提供了众多默认的PropertyEditor，若需要自定义PropertyEditor可以通过注册CustomEditorConfigurer实现
  • Spring提供了众多Aware，若需要自定义Aware可以通过BeanPostProcessor实现
  • BeanFactoryPostProcessor用于在实例化bean之前对BeanFactory做额外的动作 如，PropertyResourceConfigurer用来将PlaceholderResolvingStringValueResolver注册到BeanFactory的embeddedValueResolvers中
• [BeanDefinitionRegistryPostProcessor](#激活BeanFactoryPostProcessor - AbstractApplicationContext invokeBeanFactoryPostProcessors “wikilink”)用于在实例化bean之前（动态）注册额外的BeanDefinition ^fa1ce8
• BeanPostProcessor用于在调用bean的init-method前后，对实例化完成的bean做一些额外的干预 如，CommonAnnotationBeanPostProcessor用来处理@PostConstructor，AbstractAdvisingBeanPostProcessor用来实现AOP

ApplicationContext具体实现类 - AnnotationConfigApplicationContext

1
2
3
4
5

public AnnotationConfigApplicationContext(Class<?>... componentClasses) { 
    this(); //1. 首先会调用自己的无参构造 
    register(componentClasses); //2. 然后注册我们传入的配置类 
    refresh(); //3. 最后进行刷新操作（关键） 
}

无参构造

1
2
3
4
5
6
7
8

public AnnotationConfigApplicationContext() {
        StartupStep createAnnotatedBeanDefReader = this.getApplicationStartup().start("spring.context.annotated-bean-reader.create");
      //创建AnnotatedBeanDefinitionReader对象，用于后续处理 @Bean 注解
        this.reader = new AnnotatedBeanDefinitionReader(this);
        createAnnotatedBeanDefReader.end();
      //创建ClassPathBeanDefinitionScanner对象，用于扫描类路径上的Bean
        this.scanner = new ClassPathBeanDefinitionScanner(this);
}

AnnotatedBeanDefinitionReader

1
2
3
4
5
6
7
8

public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry, Environment environment) {
        Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
        Assert.notNull(environment, "Environment must not be null");
        this.registry = registry;
        this.conditionEvaluator = new ConditionEvaluator(registry, environment, null);
      //这里注册了注解处理配置相关的后置处理器
        AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
}

这里会将ConfigurationClassPostProcessor后置处理器加入到BeanFactory中，它继承自BeanFactoryPostProcessor，也就是说一会会在BeanFactory初始化完成之后进行后置处理，同时这里也会注册一个AutowiredAnnotationBeanPostProcessor后置处理器到BeanFactory，它继承自BeanPostProcessor，用于处理后续生成的Bean对象，其实看名字就知道，这玩意就是为了处理@Autowire、@Value这种注解，用于自动注入

注册传入的配置类 - register

1
2
3
4
5
6
7
8
9

@Override
public void register(Class<?>... componentClasses) {
        Assert.notEmpty(componentClasses, "At least one component class must be specified");
        StartupStep registerComponentClass = this.getApplicationStartup().start("spring.context.component-classes.register")
                .tag("classes", () -> Arrays.toString(componentClasses));
      //使用我们上面创建的Reader注册配置类
        this.reader.register(componentClasses);
        registerComponentClass.end();
}

[Refresh](#AbstractApplicationContext Refresh “wikilink”)

==TODO==

• ☒ Spring AOP
• ☐ 注解运行逻辑
  • @Component与@Bean的区别
  • JavaSSM#^473168
  • ☐ @Bean 在处理属性注入时？
• ☒ AnnotationConfigApplicationContext - 与 配置类的关系 - 具体例子
• ☐ BeanDefinitionReader和BeanDefinitionRegistry
• ☐ 完善调用链图

  配置类的注册 - ConfigurationClassPostProcessor

ConfigurationClassPostProcessor继承自BeanDefinitionRegistryPostProcessor -> BeanFactoryPostProcessor，这个后置处理器是Spring中提供的，这是专门用于处理配置类的后置处理器，其中ImportBeanDefinitionRegistrar，还有ImportSelector都是靠它来处理

ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry

内部调用 processConfigBeanDefinitions(BeanDefinitionRegistry) 方法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
    // 将Spring认为可能是配置类的候选类加入candidates，例如@Configuration、@Component
    // @ComponentScan、@Import，以及通过实现ImportSelector或ImportBeanDefinitionRegistrar间接引入的配置
    List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
    // 直接取出所有已注册Bean的名称
    String[] candidateNames = registry.getBeanDefinitionNames();
    for (String beanName : candidateNames) {
       // 依次拿到对应的Bean定义，然后进行判断
       BeanDefinition beanDef = registry.getBeanDefinition(beanName);
       if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {
          ...
       }
       // 检查一个Bean定义是否符合作为配置类的条件，即使它没有直接使用@Configuration注解
       else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
          configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
       }
    }
    // 如果一个打了 @Configuration 的类都没发现，直接返回
    if (configCandidates.isEmpty()) {
       return;
    }
    // 对所有的配置类依据 @Order 进行排序
    configCandidates.sort((bd1, bd2) -> {
       int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
       int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
       return Integer.compare(i1, i2);
    });
    ...
    // 这里使用do-while语句依次解析所有的配置类
    ConfigurationClassParser parser = new ConfigurationClassParser(
          this.metadataReaderFactory, this.problemReporter, this.environment,
          this.resourceLoader, this.componentScanBeanNameGenerator, registry);
    Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
    Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
    do {
       StartupStep processConfig = this.applicationStartup.start("spring.context.config-classes.parse");
       //这里就会通过Parser解析配置类中大部分内容，包括我们之前遇到的@Import注解
             parser.parse(candidates);
             parser.validate();
       //解析完成后读取到所有的配置类
       Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
             configClasses.removeAll(alreadyParsed);
       ... 
       //将上面读取的配置类加载为Bean
       this.reader.loadBeanDefinitions(configClasses);
       ...
    }
    while (!candidates.isEmpty());
    ...
}

ConfigurationClassParser#parse(candidates)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public void parse(Set<BeanDefinitionHolder> configCandidates) {
    for (BeanDefinitionHolder holder : configCandidates) {
        BeanDefinition bd = holder.getBeanDefinition();
        try {
            if (bd instanceof AnnotatedBeanDefinition annotatedBeanDef) {
                parse(annotatedBeanDef, holder.getBeanName());
            }
            else if (bd instanceof AbstractBeanDefinition abstractBeanDef && abstractBeanDef.hasBeanClass()) {
                parse(abstractBeanDef.getBeanClass(), holder.getBeanName());
            }
            else {
                parse(bd.getBeanClassName(), holder.getBeanName());
            }
        }
        catch (BeanDefinitionStoreException ex) {
            throw ex;
        }
        catch (Throwable ex) {
            throw new BeanDefinitionStoreException(
                    "Failed to parse configuration class [" + bd.getBeanClassName() + "]", ex);
        }
    }

    this.deferredImportSelectorHandler.process();
}

内部遍历candidates中的每一个BeanDefinitionHolder，调用parse的多态方法，最终调用ConfigurationClassParser#processConfigurationClass，最后调用deferredImportSelectorHandler.process()处理DeferredImportSelector相关的Bean注册 ^processConfigurationClass

首先判断条件注释，即处理@Conditional相关注解

然后将不同来源的配置类源信息通过asSourceClass进行封装，交给最核心的调用[doProcessConfigurationClass](#ConfigurationClassParser doProcessConfigurationClass “wikilink”)

将配置类ConfigurationClass实例化为SourceClass。这样做的目的是为了让后续的处理逻辑能够通过SourceClass访问到配置类中定义的所有相关信息（比如注解信息，Meta-info），并进行相应的处理。例如，通过SourceClass可以读取配置类上的@ComponentScan注解，并执行组件扫描；读取@Import注解，并处理导入的配置类或组件；读取@Bean方法，并注册对应的Bean定义等。

ConfigurationClassParser#doProcessConfigurationClass

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

@Nullable
protected final SourceClass doProcessConfigurationClass(
        ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)
        throws IOException {

    if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
        // Recursively process any member (nested) classes first
        processMemberClasses(configClass, sourceClass, filter);
    }

    // Process any @PropertySource annotations
    for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
            sourceClass.getMetadata(), org.springframework.context.annotation.PropertySource.class,
            PropertySources.class, true)) {
        if (this.propertySourceRegistry != null) {
            this.propertySourceRegistry.processPropertySource(propertySource);
        }
        else {
            logger.info("Ignoring @PropertySource annotation on [" + sourceClass.getMetadata().getClassName() +
                    "]. Reason: Environment must implement ConfigurableEnvironment");
        }
    }

    // Search for locally declared @ComponentScan annotations first.
    Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
            sourceClass.getMetadata(), ComponentScan.class, ComponentScans.class,
            MergedAnnotation::isDirectlyPresent);

    // Fall back to searching for @ComponentScan meta-annotations (which indirectly
    // includes locally declared composed annotations).
    if (componentScans.isEmpty()) {
        componentScans = AnnotationConfigUtils.attributesForRepeatable(sourceClass.getMetadata(),
                ComponentScan.class, ComponentScans.class, MergedAnnotation::isMetaPresent);
    }

    if (!componentScans.isEmpty()) {
        List<Condition> registerBeanConditions = collectRegisterBeanConditions(configClass);
        if (!registerBeanConditions.isEmpty()) {
            throw new ApplicationContextException(
                    "Component scan could not be used with conditions in REGISTER_BEAN phase: " + registerBeanConditions);
        }
        for (AnnotationAttributes componentScan : componentScans) {
            // The config class is annotated with @ComponentScan -> perform the scan immediately
            Set<BeanDefinitionHolder> scannedBeanDefinitions =
                    this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
            // Check the set of scanned definitions for any further config classes and parse recursively if needed
            for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
                BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
                if (bdCand == null) {
                    bdCand = holder.getBeanDefinition();
                }
                if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
                    parse(bdCand.getBeanClassName(), holder.getBeanName());
                }
            }
        }
    }

    // Process any @Import annotations
    processImports(configClass, sourceClass, getImports(sourceClass), filter, true);

    // Process any @ImportResource annotations
    AnnotationAttributes importResource =
            AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
    if (importResource != null) {
        String[] resources = importResource.getStringArray("locations");
        Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
        for (String resource : resources) {
            String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
            configClass.addImportedResource(resolvedResource, readerClass);
        }
    }

    // Process individual @Bean methods
    Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
    for (MethodMetadata methodMetadata : beanMethods) {
        configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
    }

    // Process default methods on interfaces
    processInterfaces(configClass, sourceClass);

    // Process superclass, if any
    if (sourceClass.getMetadata().hasSuperClass()) {
        String superclass = sourceClass.getMetadata().getSuperClassName();
        if (superclass != null && !superclass.startsWith("java")) {
            boolean superclassKnown = this.knownSuperclasses.containsKey(superclass);
            this.knownSuperclasses.add(superclass, configClass);
            if (!superclassKnown) {
                // Superclass found, return its annotation metadata and recurse
                return sourceClass.getSuperClass();
            }
        }
    }

    // No superclass -> processing is complete
    return null;
}