源码分析java

1. Reference 和 Reference queue 精髓源码分析

每个Reference状态列表是Active、Pending、Enqueued、Inactive (本文也将基于以下这四种状态做出源码解读)

状态间主要的标识：
用Reference的成员变量queue与next（类似于单链表中的next）来标识

有了这些约束， GC 只需要检测next字段就可以知道是否需要对该引用对象(reference)采取特殊处理

什么特殊处理？
GC在状态active发送变化时，会主动把 weakReference中的 reference置null，PhantomReference 中的 reference 无视 （PhantomReference的get方法重写返回null，可能就因为这原因就没有置null了）,并给next赋值this，以及pending等。（别问我为啥，测出来的。。。。培训出来就这水平了）

描述：
active 状态下的reference会受到GC的特别对待，GC在发现对象的可达性变成合适的状态后将变更reference状态，具体是变更为pending还是Inactive，取决于是否注册了 queue

特点：

源码分析:

描述：
pending-Reference列表中的引用都是这个状态。
它们等着被内部线程ReferenceHandler处理（调用ReferenceQueue.enqueue方法）
没有注册的实例不会进入这个状态!

特点：

源码分析：

3.似乎明白了 ReferenceQueue.ENQUEUED 的含义

描述：
调用ReferenceQueue.enqueued方法后的引用处于这个状态中。
没有注册的实例不会进入这个状态。

特点：

源码分析：
可以看出 整体是一种先进后出的栈结构。head作为栈头。r.next指向成员变量 head，如果head为null，那么就指向自己（为了后面的压栈好找元素）

描述：
最终状态，处于这个状态的引用对象，状态不会在改变。

两种途径到这个状态：
1.referenceQueue 调用 reallyPoll ，
2.不注册 referenceQueue，reference state变化时。

特点：

源码分析：

引用：
https://liujiacai.net/blog/2015/09/27/java-weakhashmap/#%E5%BC%B1%E5%BC%95%E7%94%A8%EF%BC%88weak-reference%EF%BC%89

2. 源码分析之AtomicInteger

AtomicInteger 是 java.util.concurrent.atomic 包下的类，作用是提供原子操作 Integer 类。

我们知道在 Java 中， i++、++i 这种操作并不是线程安全的。主要是因为类似于 ++ 操作会被编译为2条操作指令，而多线程环境下CPU在执行过程可能会中断切换到别的线程，无法保证2条操作指令的原子性，所以是线程不安全。针对这种情况，我们可能会想到利用 synchronize 关键字实现线程同步，保证 ++ 操作的原子性，的确这是一种有效的方法，但我们还有一种选择-- AtomicInteger 。

首先先看一下 AtomicInteger 类的类变量。可以看出有个 unsafe 的类变量。

Unsafe 类是用来在任意内存亮卜地址位置处读写数据，可见，对于普通用户来说，使用起来还是比较危险的。 AtomicInteger 类本质就是利用 Unsafe.compareAndSwapInt 这个 CAS 操作方法来保证 Integer 操作的原子性。仿键隐

看一下 AtomicInteger 的对 int 的加法操作。

可以看出调用的是 Unsafe 类中的 getAndAddInt 方法，可以继续看看 getAndAddInt 的实现：

CAS 有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。 AtomicInteger 类实则是利用这一特性来保证操作的原子性，可以说通过 CAS 实现的。

CAS 虽然可以解决原子性问题，但也有其他问题，因为 CAS 需要在操作值的时候检查下值有没有发生变化备厅，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用 CAS 进行检查时会发现它的值没有发生变化，但是实际上却变化了。

3. SpringBoot内置生命周期事件详解 SpringBoot源码(十)

SpringBoot中文注释项目Github地址：

https://github.com/yuanmabiji/spring-boot-2.1.0.RELEASE

本篇接 SpringBoot事件监听机制源码分析(上) SpringBoot源码(九)

温故而知新，我们来简单回顾一下上篇的内容，上一篇我们分析了 SpringBoot启动时广播生命周期事件的原理 ，现将关键步骤再浓缩总结下：

上篇文章的侧重点是分析了SpringBoot启动时广播生命周期事件的原理，此篇文章我们再来详细分析SpringBoot内置的7种生命周期事件的源码。

分析SpringBoot的生命周期事件，我们先来看一张类结构图：

由上图可以看到事件类之间的关系：

EventObject 类是JDK的事件基类，可以说是所有Java事件类的基本，即所有的Java事件类都直接或间接继承于该类，源码如下：

可以看到 EventObject 类只有一个属性 source ，这个属性是用来记录最初事件是发生在哪个类，举个栗子，比如在SpringBoot启动过程中会发射 ApplicationStartingEvent 事件，而这个事件最初是在 SpringApplication 类中发射的，因此 source 就是 SpringApplication 对象。

ApplicationEvent 继承了DK的事件基类 EventObject 类，是Spring的事件基类，被所有Spring的具体事件类继承，源码如下：

可以看到 ApplicationEvent 有且仅有一个属性 timestamp ，该属性是用来记录事件发生的时间。

SpringApplicationEvent 类继承了Spring的事件基类 ApplicationEvent ，是所有SpringBoot内置生命周期事件的父类，源码如下：

可以看到 SpringApplicationEvent 有且仅有一个属性 args ，该属性就是SpringBoot启动时的命令行参数即标注 @SpringBootApplication 启动类中 main 函数的参数。

接下来我们再来看一下 SpringBoot 内置生命周期事件即 SpringApplicationEvent 的具体子类们。

SpringBoot开始启动时便会发布 ApplicationStartingEvent 事件，其发布时机在环境变量Environment或容器ApplicationContext创建前但在注册 ApplicationListener 具体监听器之后，标志标志 SpringApplication 开始启动。

可以看到 事件多了一个 environment 属性，我们不妨想一下，多了 environment 属性的作用是啥？
答案就是 事件的 environment 属性作用是利用事件发布订阅机制，相应监听器们可以从 事件中取出 environment 变量，然后我们可以为 environment 属性增加属性值或读出 environment 变量中的值。

当SpringApplication已经开始启动且环境变量 Environment 已经创建后，并且为环境变量 Environment 配置了命令行和 Servlet 等类型的环境变量后，此时会发布 事件。

监听 事件的第一个监听器是 ConfigFileApplicationListener ，因为是 ConfigFileApplicationListener 监听器还要为环境变量 Environment 增加 application.properties 配置文件中的环境变量；此后还有一些也是监听 事件的其他监听器监听到此事件时，此时可以说环境变量 Environment 几乎已经完全准备好了。

可以看到 事件多了个 类型的 context 属性， context 属性的作用同样是为了相应监听器可以拿到这个 context 属性执行一些逻辑，具体作用将在 3.4.4 详述。

事件在 ApplicationContext 容器创建后，且为 ApplicationContext 容器设置了 environment 变量和执行了 的初始化方法后但在bean定义加载前触发，标志ApplicationContext已经初始化完毕。

同样可以看到 ApplicationPreparedEvent 事件多了个 类型的 context 属性，多了 context 属性的作用是能让监听该事件的监听器们能拿到 context 属性，监听器拿到 context 属性一般有如下作用：

ApplicationPreparedEvent 事件在 ApplicationContext 容器已经完全准备好时但在容器刷新前触发，在这个阶段 bean 定义已经加载完毕还有 environment 已经准备好可以用了。

ApplicationStartedEvent 事件将在容器刷新后但 ApplicationRunner 和 CommandLineRunner 的 run 方法执行前触发，标志 Spring 容器已经刷新，此时容器已经准备完毕了。

ApplicationReadyEvent 事件在调用完 ApplicationRunner 和 CommandLineRunner 的 run 方法后触发，此时标志 SpringApplication 已经正在运行。

可以看到 ApplicationFailedEvent 事件除了多了一个 context 属性外，还多了一个 Throwable 类型的 exception 属性用来记录SpringBoot启动失败时的异常。

ApplicationFailedEvent 事件在SpringBoot启动失败时触发，标志SpringBoot启动失败。

此篇文章相对简单，对SpringBoot内置的7种生命周期事件进行了详细分析。我们还是引用上篇文章的一张图来回顾一下这些生命周期事件及其用途：

由于有一些小伙伴们建议之前有些源码分析文章太长，导致耐心不够，看不下去，因此，之后的源码分析文章如果太长的话，笔者将会考虑拆分为几篇文章，这样就比较短小了，比较容易看完，嘿嘿。

【源码笔记】Github地址：

https://github.com/yuanmabiji/Java-SourceCode-Blogs

点赞搞起来，嘿嘿嘿！

公众号【 源码笔记 】专注于Java后端系列框架的源码分析。

4. JAVA源码解析的时候 Character.MIN_RADIX为什么=2

‘’占一个位，你想一下，如果值是1，那么你怎么输入汉字

Character类的使用方法
Character：字符类型
1、属性。
static int MIN_RADIX ：返回最小基数。

5. HashMap源码分析

HashMap（jdk 1.8）
  使用哈希表存储键值对，底层是一个存储Node的table数组。其基本的运行逻辑是，table数组的每一个元素是一个槽，用于存储Node对象，向Hash表中插入键值对时，首先计算键的hash值，并对数组容量（即数组长度）取余，定位该键值对应放在哪个槽中，若槽中已经存在元素（即哈希冲突），将Node节点插入到冲突链表尾端，当该槽中结点超过一定数量（默认为8）并且哈希表容量超过一定值（默认为64）时，对该链表进行树化。低于一定数量（默认为6）后进行resize时，树形结构又会链表化。当哈希表的总节点数超过阈值时，对哈希表进行扩容，容量翻倍。

由于哈希表需要用到key的哈希函数，因此对于自定义类作为key使用哈希表时，需要重写哈希函数，保证相等的key哈希值相同。

由于扩容或树化过程Node节点的位置会发生改变，因此哈希表是无序的，不同时期遍历同一张哈希表，得到的节点顺序会不同。

成员变量

    Hash表的成员变量主要有存储键值对的table数组，size，装载因子loadFactory，阈值theshold，容量capacity。

table数组：

哈希表的实质就是table数组，它用来存储键值对。哈希表中内部定义了Node类来封装键值对。

 Node类实现了Map的Entry接口。包括key，value，下一个Node指针和key的hash值。

 容量Capacity：

HashMap中没有专门的属性存储容量，容量等于table.lenth，即数组的长度，默认初始化容量为16。初始化时，可以指定哈希表容量，但容量必须是2的整数次幂，在初始化过程中，会调用tableSizeFor函数，得到一个不小于指定容量的2的整数次幂，暂时存入到threshold中。

注意，若容量设置过大，那么遍历整个哈希表需要耗费更多的时间。

    阈值threshold：

指定当前hash表最多存储多少个键值对，当size超过阈值时，hash表进行扩容，扩容后容量翻倍。

   loadFactory：

threshold=capacity*loadFactory。

装填因子的大小决定了哈希表存储键值对数量的能力，它直接影响哈希表的查找性能。初始化时可以指定loadFactory的值，默认为0.75。

 初始化过程

哈希闹做表有3个构造函数，用户可以指定哈希表的初始容量和装填因子，但初始化过程只是简单填入这两个参数，table数组并没有初始化。注意，这里的initialCapacity会向上取2的整数次幂并暂时保存到threshold中。

table数组的初始化是在第一次插入键值对时触发，实际在resize函数中进行初始化。

hash过程与下标计算

哈希表是通过key的哈希值决定Node放入哪个槽中，察毁 在java8中 ，hash表没有直接用key的哈希值，而是自定义了hash函数。

哈希表中的key可以为null，若为null，哈希值为0，否则哈希值（一共32位）的高16位不变，低16位与高16位进行异或操作，得到新的哈希值。（h >>> 16，液没衡表示无符号右移16位，高位补0，任何数跟0异或都是其本身，因此key的hash值高16位不变。）

之所以这样处理，是与table的下标计算有关

因为，table的长度都是2的幂，因此index仅与hash值的低n位有关（n-1为0000011111的形式），hash值的高位都被与操作置为0了，相当于hash值对n取余。

由于index仅与hash值的低n位有关，把哈希值的低16位与高16位进行异或处理，可以让Node节点能更随机均匀得放入哈希表中。

get函数：

V  get(Object key) 通过给定的key查找value

先计算key的哈希值，找到对应的槽，遍历该槽中所有结点，如果结点中的key与查找的key相同或相等，则返回value值，否则返回null。

注意，如果返回值是null，并不一定是没有这种KV映射，也有可能是该key映射的值value是null，即key-null的映射。也就是说，使用get方法并不能判断这个key是否存在，只能通过containsKey方法来实现。

put函数

V put(K key, V value) 存放键值对

计算key的哈希值，找到哈希表中对应的槽，遍历该链表，如果发现已经存在包含该key的Node，则把新的value放入该结点中，返回该结点的旧value值（旧value可能是null），如果没有找到，则创建新结点插入到 链表尾端 （java7使用的是头插法），返回null。插入结点后需要判断该链表是否需要树化，并且判断整个哈希表是否需要扩容。

由该算法可以看出，哈希表中不会有两个key相同的键值对。

resize函数

    resize函数用来初始化或扩容table数组。主要做了两件事。

1.根据table数组是否为空判断初始化还是扩容，计算出相应的newCap和newThr，新建table数组并设置新的threshold。

2.若是进行扩容，则需要将原数组中的Node移植到新的数组中。

由于数组扩容，原来键值对可能存储在新数组不同的槽中。但由于键值对位置是对数组容量取余（index=hash(key)&(Capacity-1)）,由于Capacity固定为2的整数次幂，并新的Capacity（newCap）是旧的两倍（oldCap）。因此，只需要判断每个Node中的hash值在oldCap二进制那一位上是否为0(hash&oldCap==0)，若为0，对newCap取余值与oldCap相同，Node在新数组中槽的位置不变，若为1，新的位置是就得位置加一个oldCap值。

因此hashMap的移植算法是，遍历旧的槽：

若槽为空，跳过。

若槽只有一个Node，计算该Node在新数组中的位置，放入新槽中。

若槽是一个链表，则遍历这个链表，分别用loHead，loTail,hiHead,hiTail两组指针建立两个链表，把hash值oldCap位为0的Node节点放入lo链表中，hash值oldCap位为1的节点放入hi链表中，之后将两个链表分别插入到新数组中，实现原键值对的移植。

lo链表放入新数组原来位置，hi链表放入新数组原来位置+oldCap中

树化过程 ：

当一个槽中结点过多时，哈希表会将链表转换为红黑树，此处挖个坑。

[总结] java8中hashMap的实现原理与7之间的区别：

1.hash值的计算方法不同 2.链表采用尾插法，之前是头插法 3.加入了红黑树结构

6. [Spring boot源码解析] 2 启动流程分析

在了解 Spring Boot 的启动流程的时候，我们先看一下一个Spring Boot 应用是如何启动的，如下是一个简单的 SpringBoot 程序，非常的简洁，他是如何做到的呢，我们接下来就将一步步分解。

我们追踪 SpringApplication.run() 方法，其实最终它主要的逻辑是新建一个 SpringApplication ，然后调用他的 run 方法，如下:

我们先来看一下创建 SpringApplication 的方法：

在将Main class 设置 primarySources 后，调用了 WebApplicationType.deceFromClasspath() 方法，该方法是为了检查当前的应用类型，并设置给 webApplicationType 。 我们进入 deceFromClasspath 方法 ：

这里主要是通过类加载器判断是否存在 REACTIVE 相关的类信息，假如有就代表是一个 REACTIVE 的应用，假如不是就检查是否存在 Servelt 和 ，假如都没有，就代表应用为非 WEB 类应用，返回 NONE ，默认返回 SERVLET 类型，我们这期以我们目前最常使用的 SERVLET 类型进行讲解，所以我们在应用中引入了 spring-boot-starter-web 作为依赖：

他会包含 Spring-mvc 的依赖，所以就包含了内嵌 tomcat 中的 Servlet 和 Spring-web 中的 ,因此返回了 SERVLET 类型。

回到刚才创建 SpringApplication 的构建方法中，我们设置完成应用类型后，就寻找所有的 Initializer 实现类，并设置到 SpringApplication 的 Initializers 中，这里先说一下 getSpringFactoriesInstances 方法，我们知道在我们使用 SpringBoot 程序中，会经常在 META-INF/spring.factories 目录下看到一些 EnableAutoConfiguration ，来出发 config 类注入到容器中，我们知道一般一个 config 类要想被 SpringBoot 扫描到需要使用 @CompnentScan 来扫描具体的路径，对于 jar 包来说这无疑是非常不方便的，所以 SpringBoot 提供了另外一种方式来实现，就是使用 spring.factories ，比如下面这个，我们从 Springboot-test 中找到的例子，这里先定义了一个ExampleAutoConfiguration，并加上了 Configuration 注解：

然后在 spring.factories 中定义如下：

那这种方式是怎么实现的你，这就要回到我们刚才的方法 getSpringFactoriesInstances :

我们先来看一下传入参数，这里需要注意的是 args，这个是初始化对应 type 的时候传入的构造参数，我们先看一下 SpringFactoriesLoader#loadFactoryNames 方法：

首先是会先检查缓存，假如缓存中存在就直接返回，假如没有就调用 classLoader#getResources 方法，传入 META-INF/spring.factories ，即获取所有 jar 包下的对应文件，并封装成 UrlResource ，然后使用 PropertiesLoaderUtils 将这些信息读取成一个对一对的 properties，我们观察一下 spring.factories 都是按 properties 格式排版的，假如有多个就用逗号隔开，所以这里还需要将逗号的多个类分隔开来，并加到 result 中，由于 result 是一个 LinkedMultiValueMap 类型，支持多个值插入，最后放回缓存中。最终完成加载 META-INF/spring.factories 中的配置，如下：

我们可以看一下我们找到的 initializer 有多少个：

在获取到所有的 Initializer 后接下来是调用 方法进行初始化。

这里的 names 就是我们上面通过类加载器加载到的类名，到这里会先通过反射生成 class 对象，然后判断该类是否继承与 ApplicationContextInitializer ，最后通过发射的方式获取这个类的构造方法，并调用该构造方法，传入已经定义好的构造参数，对于 ApplicationContextInitializer 是无参的构造方法，然后初始化实例并返回，回到原来的方法，这里会先对所有的 ApplicationContextInitializer 进行排序，调用 #sort(instances) 方法，这里就是根据 @Order 中的顺序进行排序。

接下来是设置 ApplicationListener ，我们跟进去就会发现这里和上面获取 ApplicationContextInitializer 的方法如出一辙，最终会加载到如图的 15 个 listener （这里除了 外，其他都是 SpringBoot 内部的 Listener）:

在完成 SpringApplication 对象的初始化后，我们进入了他的 run 方法，这个方法几乎涵盖了 SpringBoot 生命周期的所有内容，主要分为九个步骤，每一个步骤这里都使用注解进行标识：

主要步骤如下：
第一步：获取 SpringApplicationRunListener， 然后调用他的 staring 方法启动监听器。
第二步：根据 SpringApplicationRunListeners以及参数来准备环境。
第三步：创建 Spring 容器。
第四步：Spring 容器的前置处理。
第五步：刷新 Spring 容器。
第六步： Spring 容器的后置处理器。
第七步：通知所有 listener 结束启动。
第八步：调用所有 runner 的 run 方法。
第九步：通知所有 listener running 事件。
我们接下来一一讲解这些内容。

我们首先看一下第一步，获取 SpringApplicationRunListener :

这里和上面获取 initializer 和 listener 的方式基本一致，都是通过 getSpringFactoriesInstances , 最终只找到一个类就是： org.springframework.boot.context.event.EventPublishingRunListener ，然后调用其构造方法并传入产生 args , 和 SpringApplication 本身:

我们先看一下构造函数，首先将我们获取到的 ApplicationListener 集合添加到initialMulticaster 中， 最后都是通过操作 来进行广播，我，他继承于 ，我们先看一下他的 addApplicationListener 方法：

我们可以看出，最后是放到了 applicationListenters 这个容器中。他是 defaultRetriever 的成员属性， defaultRetriever 则是 的私有类，我们简单看一下这个类：

我们只需要看一下这里的 getApplicationListeners 方法，它主要是到 beanFactory 中检查是否存在多的 ApplicationListener 和旧的 applicationListeners 组合并返回，接着执行 listener 的 start 方法，最后也是调用了 的 multicastEvent 查找支持对应的 ApplicationEvent 类型的通知的 ApplicationListener 的 onApplicationEvent 方法 ,这里除了会:

筛选的方法如下，都是调用了对应类型的 supportsEventType 方法 ：

如图，我们可以看到对 org.springframework.boot.context.event.ApplicationStartingEvent 感兴趣的有5个 Listener

环境准备的具体方法如下：

首先是调用 getOrCreateEnvironment 方法来创建 environment ，我们跟进去可以发现这里是根据我们上面设置的环境的类型来进行选择的，当前环境会创建 StandardServletEnvironment

我们先来看一下 StandardServletEnvironment 的类继承关系图，我们可以看出他是继承了 AbstractEnvironment ：

他会调用子类的 customizePropertySources 方法实现,首先是 StandardServletEnvironment 的实现如下，他会添加 servletConfigInitParams , servletContextInitParams , jndiProperties 三种 properties，当前调试环境没有配置 jndi properties，所以这里不会添加。接着调用父类的 customizePropertySources 方法，即调用到了 StandardEnvironment 。

我们看一下 StandardEnvironment#customizePropertySources 方法，与上面的三个 properties 创建不同，这两个是会进行赋值的，包括系统环境变量放入 systemEnvironment 中，jvm 先关参数放到 systemProperties 中：

这里会添加 systemEnvironment 和 systemProperties 这两个 properties，最终拿到的 properties 数量如下 4个：

在创建完成 Environment 后，接下来就到了调用 configureEnvironment 方法：

我们先看一下 configurePropertySources 方法，这里主要分两部分，首先是查询当前是否存在 defaultProperties ，假如不为空就会添加到 environment 的 propertySources 中，接着是处理命令行参数，将命令行参数作为一个 CompositePropertySource 或则 添加到 environment 的 propertySources 里面，

接着调用 ConfigurationPropertySources#attach 方法,他会先去 environment 中查找 configurationProperties , 假如寻找到了，先检查 configurationProperties 和当前 environment 是否匹配，假如不相等，就先去除，最后添加 configurationProperties 并将其 sources 属性设置进去。

回到我们的 prepareEnvironment 逻辑，下一步是通知观察者，发送 事件，调用的是 SpringApplicationRunListeners#environmentPrepared 方法，最终回到了 #multicastEvent 方法，我们通过 debug 找到最后对这个时间感兴趣的 Listener 如下：

其主要逻辑如下：

这个方法最后加载了 PropertySourceLoader , 这里主要是两种，一个是用于 Properties 的，一个是用于 YAML 的如下：

其中 apply 方法主要是加载 defaultProperties ，假如已经存在，就进行替换，而替换的目标 PropertySource 就是 load 这里最后的一个 consumer 函数加载出来的，这里列一下主要做的事情：
1、加载系统中设置的所有的 Profile 。
2、遍历所有的 Profile ，假如是默认的 Profile ， 就将这个 Profile 加到 environment 中。
3、调用load 方法，加载配置，我们深入看一下这个方法：

他会先调用 getSearchLocations 方法，加载所有的需要加载的路径，最终有如下路径：

其核心方法是遍历所有的 propertySourceLoader ，也就是上面加载到两种 propertySourceLoader ,最红 loadForFileExtension 方法，加载配置文件，这里就不展开分析了，说一下主要的作用，因为每个 propertySourceLoader 都有自己可以加载的扩展名，默认扩展名有如下四个 properties, xml, yml, yaml，所以最终拿到文件名字，然后通过 - 拼接所有的真实的名字，然后加上路径一起加载。

接下来，我们分析 BackgroundPreinitializer ,这个方法在接收 ApplicationPrepareEnvironment 事件的时候真正调用了这份方法：

1、 ConversionServiceInitializer 主要负责将包括 日期，货币等一些默认的转换器注册到 formatterRegistry 中。
2、 ValidationInitializer 创建 validation 的匹配器。
3、 MessageConverterInitializer 主要是添加了一些 http 的 Message Converter。
4、 JacksonInitializer 主要用于生成 xml 转换器的。
接着回到我们将的主体方法， prepareEnvironment 在调用完成 listeners.environmentPrepared(environment) 方法后，调用 bindToSpringApplication(environment) 方法，将 environment 绑定到 SpirngApplication 中。
接着将 enviroment 转化为 StandardEnvironment 对象。
最后将 configurationProperties 加入到 enviroment 中， configurationProperties 其实是将 environment 中其他的 PropertySource 重新包装了一遍，并放到 environment 中，这里主要的作用是方便 进行解析。

它主要是检查是否存在 spring.beaninfo.ignore 配置，这个配置的主要作用是设置 javaBean 的内省模式，所谓内省就是应用程序在 Runtime 的时候能检查对象类型的能力，通常也可以称作运行时类型检查，区别于反射主要用于修改类属性，内省主要用户获取类属性。那么我们什么时候会使用到内省呢，java主要是通过内省工具 Introspector 来完成内省的工作，内省的结果通过一个 Beaninfo 对象返回，主要包括类的一些相关信息，而在 Spring中，主要是 BeanUtils#Properties 会使用到，Spring 对内省机制还进行了改进，有三种内省模式，如下图中红色框框的内容，默认情况下是使用 USE_ALL_BEANINFO。假如设置为true，就是改成第三中 IGNORE_ALL_BEANINFO

首先是检查 Application的类型，然后获取对应的 ApplicationContext 类，我们这里是获取到了 org.springframework.boot.web.servlet.context. 接着调用 BeanUtils.instantiateClass(contextClass); 方法进行对象的初始化。

最终其实是调用了 的默认构造方法。我们看一下这个方法做了什么事情。这里只是简单的设置了一个 reader 和一个 scanner，作用于 bean 的扫描工作。

我们再来看一下这个类的继承关系

这里获取 ExceptionReporter 的方式主要还是和之前 Listener 的方式一致,通过 getSpringFactoriesInstances 来获取所有的 SpringBootExceptionReporter 。

其主要方法执行如下：

7. 如何读JAVA源码

最好下个编辑器，editplus，gvim之类的，我用的是gvim，当然有myeclipse之类的软件就更好，将代码引进去，然后从主类开始，先看一遍主类，大体知道是干嘛的就好了，然后再细看，从上到下，当看到新类时，再转过去看那个类，看懂了再回主类继续，